Re: [Openjnlp-devel] openjnlp.properties vs. a resource bundle

[Kevin H. <ke...@na...>]

On Sunday, February 17, 2002, at 10:27 , Christopher Heiny wrote:

> We're bumping into some problems with the location of the
> lib/openjnlp.properties files.  Since we can't control what directory 
> the
> user will invoke OpenJNLP from, or where they will install it, this is
> causing problems (especially in Windows).

I realized almost since release of the newer launcher that it was 
tragically flawed in that regard. Relying on a filesystem structure for 
operation is so wrong.

> Do you see any difficulty with converting the info in 
> openjnlp.properties
> into a resource bundle and putting that in the .jar?  The idea would be 
> to
> name resources like this
> 	launcher.<resource>.<os>

I've been kicking around the idea of doing this. Essentially my thoughts 
are along the lines of putting "/lib/launcher.properties" inside the 
openjnlp-lib.jar and then merging all of the OS-specific launcher 
properties into one file. I was thinking more of a naming convention of 
"launcher.<os>.<resource>" which seems more consistent with properties 
file conventions, but that's a minor detail. The synthesis of the 
correct platform could easily be added to org.nanode.launcher.Gestalt, 
since it already figures out the OS type.

To get around the user-editable issue, the launcher could look in like 
"${user.home}/.jnlp/openjnlp.properties" for launcher property 
overrides, falling back to the "/lib/launcher.properties" resource if 
necessary.

None of this solves the classpath issue for launching call. Figuring out 
the correct classpath needs to be done in some fashion better than 
hardcoding relative paths in a classpath property. I used to have logic 
in the launcher that stripped the classpath values out of the 
"java.class.path" property, which might work.

On Windows, when trying to tie ".jnlp" files to OpenJNLP, I found that 
when Windows opens the file the current directory is where the ".jnlp" 
file is, not the OpenJNLP.bat location. There's no way to know where the 
"home" of OpenJNLP is.

Some strategies I've considered are:

      1) Write a registry key value for the install location
          -JWS does this, it's very Windows-ish but it also requires 
special code
          -what happens with multiple installs?

      2) Have OpenJNLP write something to a file like 
"${user.home}/.jnlp/openjnlp.properties"
         identifying where the home directory is
          -the batch file would need to be modified, is it possible to 
parse props files from DOS?
          -what happens with multiple installs?

      3) Use "${java.class.path}" to find the actual location of the jars 
needed for the launcher
          -the "${launch.classpath}" property would be supplanted by a 
list of needed jars
          -the Launcher would be updated to pick those jars out of the 
current classpath
          -multiple installs are not an issue

      4) Copy the launcher jars into a known location like 
"${user.home}/.jnlp/launcher" so they
         are in a known location
          -breaks if running in a read-only environment
          -creates updating issues
          -eliminates multiple install problem
          -enables OpenJNLP to be launched via Java Web Start

I'm kind of favoring option 3 as the cleanest. Any and all feedback 
welcome.

Now some random thoughts that are somewhat related to this:

      -Getting OpenJNLP to work as a JNLP app is powerful, and I think 
important to supplant
       JWS, especially with Java2 1.4 now out.

      -The JNLP-borne version of OpenJNLP could just be an installer, 
therefore running within
       JWS would not be an issue for launching.

      -Mac OS Classic launching is not really an issue, since it has a 
very specific solution.
       There is also going to be a new Java 1.1 product for OpenJNLP and 
that will be the place
       where Mac OS Classic launching needs to be. OpenJNLP doesn't need 
it since it's Java2 only.

      -On Windows OpenJNLP will need to modify the registry somehow 
anyway to set up the document
       mapping. It also needs to be done on Mac OS X. I've already 
investigated both of these and
       have JNI-style Java interfaces into the necessary calls figured 
out (for the most part).

      -I'd like to do some integrating of OpenJNLP into KDE or Gnome or 
both on linux. I don't
       really know how either desktop environment is structured for doing 
mappings and icons
       and stuff, so any ideas here would be awesome. I'm ambivelant 
about Solaris and CDE.

      -JavaWorld has tips on self-executing jars where basically you 
embed all of your
       app as resources in a jar and then write a Java extraction utility 
that is identified as
       the main-class in the manifest. This would enable the "install" of 
OpenJNLP by double-clicking
       the jar. I see this as a possible excellent solution for 
guaranteeing Java is present before
       OpenJNLP gets installed, since the jar won't execute without Java. 
This installer could also
       be used as the JNLP installer for JWS. Thoughts?


There. Launching issues aren't so simple, are they?