I figured out for the time being how I can programmatically handle setting
security that might be cross-platform for my application.
Past that it doesn’t seem to be finding resources off the class loader that it
should be…
With this…
ClassLoader cl = Thread.currentThread().getContextClassLoader();
syslog.println("cl is " + cl + "\nuser.dir " +
System.getProperty("user.dir") + "\nCP> " +
System.getProperty("java.class.path"));
I get this…
cl is jdk.internal.loader.ClassLoaders$AppClassLoader@55054057
user.dir /Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/Java
CP>
/Users/mjh/HalfPipe/HalfPipe_jpkg/outputdir/HalfPipe.app/Contents/Java/halfpipe.jar:RserveEngine.jar:quartz-jobs-2.2.2.jar:commons-logging-1.1.1.jar:httpcore-4.4.10.jar:groovy-all-2.6.0-alpha-1.jar:
…
:resource.jar
...
…and so on...
Only the first path in java.class.path is absolute - to the main jar. Would
this break if the application is moved? The other paths are relative. I notice
user.dir is now default set directly to the Java directory within the app. I
assume this is how relative is supposed to work. This is again a change from
legacy OS X java app’s. Prior to the OS X port I think Apple set this to the
parent directory of the application itself. With AppBundler set up during the
port it was set to the user home directory. I think for security concerns?
(App’s should usually be in the Application directory, this should not be
written to by the application). So this is another change that legacy app’s
could have issues with.
It might be a thought to document some of the differences to legacy java
applications somewhere?
Anyhow, I put the resources that I am currently not finding in the resource.jar
shown above. I thought some testing with non-jpackage apps showed this would
work. These used to be in the “Classes” directory as mentioned in an earlier
post. A rather obscure feature probably not many app’s took advantage of. But I
am now not finding them in the jpackage resource.jar for some reason still to
be determined.
Like…
BufferedReader rdr = new
BufferedReader(new
InputStreamReader(cl.getResourceAsStream("Scripts/loader.js")));
org.mozilla.javascript.EvaluatorException: Couldn't open file "Scripts/mm.js".
(unnamed script#1)
at
org.mozilla.javascript.DefaultErrorReporter.runtimeError(DefaultErrorReporter.java:77)
at
org.mozilla.javascript.DefaultErrorReporter.error(DefaultErrorReporter.java:64)
at org.mozilla.javascript.Context.reportError(Context.java:956)
Actually what it says it’s not finding isn’t loader.js but a script that
loader.js should load? So maybe again this is some difference in how a nested
load works? Again, it would be different application behavior somehow if so.
