Application starts and exists quickly on macOS Monterey about jdeploy

[shannah]

I tried installing it and running it on Mojave, and found the same thing.

The main difference between running on the command-line and running by double-clicking is the environment (e.g. environment vars and CWD).

One thing that may shed some light, is that I checked the Console while launching the app by both double-clicking and by running it in the CLI. I noticed the following error message only when launching by double-click:

Non-fatal error enumerating at , continuing: Error Domain=NSCocoaErrorDomain Code=260 "The file “PlugIns” couldn’t be opened because there is no such file." UserInfo={NSURL=PlugIns/ -- file:///Users/shannah/Applications/jDeploy%20Apps/OSGi.fx.app/Contents/, NSFilePath=/Users/shannah/Applications/jDeploy Apps/OSGi.fx.app/Contents/PlugIns, NSUnderlyingError=0x7fb863630a00 {Error Domain=NSPOSIXErrorDomain Code=2 "No such file or directory"}}

After that it also shows:

27366555: RECEIVED OUT-OF-SEQUENCE NOTIFICATION: 310 vs 2487, 513,

Then finally

-[PersistentAppsSupport applicationQuit:] | for app:OSGi.fx, _appTrackingState = 2

-[PersistentAppsSupport applicationQuit:] | App: OSGi.fx, quit, updating active tracking timer

Not sure if that helps you at all.

[shannah]

Can you create a test project that reproduces this issue and share it on GitHub so that I can take a look?

[amitjoy]

@shannah Thanks a lot for your quick response. I also noticed the same errors in syslogs.

In addition, I have also encountered another problem that Java modules-related java options (--add-exports or --add-opens) don't work as well even if I start the application on console. That's pretty weird. I also installed the app using npm install osgifx -g, the application starts but none of the configured java options are set while starting the VM.

It would be best if you can checkout or fork https://github.com/amitjoy/osgifx project and run build.sh in the root directory.

This will internally build the project and native installers using jpackage. Note that, the built artifacts will be stored in the target directory inside com.osgifx.console.dist.

The build.gradle in com.osgifx.console.dist contains the configurations for building installers using jpackage and the actual referenced configuration values are extracted from cnf/ext/jpackage.bnd.

In case of issues, please ping me. I will try to reply asap.

[shannah]

Are the --add-exports and --open-exports really necessary? Since you have the javafx=true option set, it will run in a JVM that has JavaFX - and, by default, it just runs your app using the -jar flag.

Admittedly, I haven't delved too deep into jpms, so i could be missing something, but I don't think they should be necessary.

[amitjoy]

They are actually necessary since the JavaFX modules need to be exposed to other unnamed modules. Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: Steve Hannah ***@***.***> Sent: Wednesday, April 6, 2022 9:37:25 PM To: shannah/jdeploy ***@***.***> Cc: Amit Mondal ***@***.***>; Author ***@***.***> Subject: Re: [shannah/jdeploy] Application starts and exists quickly on macOS Monterey (Issue #55) Are the --add-exports and --open-exports really necessary. Since you have the javafx=true option set, it will run in a JVM that has JavaFX - and, by default, it just runs your app using the -jar flag. Admittedly, I haven't delved too deep into jpms, so i could be missing something, but I don't think they should be necessary. — Reply to this email directly, view it on GitHub<#55 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADGCUVUHPDRQLV4F6ACRWBLVDXRXLANCNFSM5SWQBGDQ>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[shannah]

I have found the issue. It seems that your app's launcher tries to extract some files inside the current working directory. It needs to create a directory named ".osgifx-ws" in the CWD. When running launching by double-clicking, the current working directory isn't explicitly set anywhere - so I'm not sure where it is. But I suspect it results in an attempted write where it doesn't have permission.

I'm not sure if you have control over where it tries to extract this directory.

I'm going to add a sensible, and well-defined default for the CWD (i.e. the user.dir system property). I'm leaning toward just making it the user's home directory.

[amitjoy]

With the recent fix, now the current working directory is set to user.home if I run the application by double clicking on it, right?

[shannah]

You will need to download and install again from the download page, since the fix is in the app launcher itself. I just downloaded it and tried it myself and it appears to be working now.

Edit: But the answer is "yes", the current working directory will be set to user.home when you run the app by double-clicking.

[amitjoy]

It now works perfectly. The only problem I now have that we still need to set the java modules-related options explicitly otherwise lots of modules will not be visible to unnamed modules. Since the OSGi.fx is itself built on OSGi, it is very much required. Anyways I will create a separate issue now to track the changes. Thanks a lot for your quick support.