openjnlp-devel

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

[Christopher H. <he...@ez...>]

Hi Kevin, all

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).

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>
For example, launcher.main.unix, and synthesize the names based on OS flavor 
before looking them up.

This means that the info will no longer be user editable, but I'm not sure 
that's a good idea anyways.  On the other hand, it would probably enable the 
discard of the fancy Mac OS classic code in Launcher.

				Thanks,
					Chris

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?

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

[Christopher H. <he...@ez...>]

On Monday 18 February 2002 11:53, Kevin Herrboldt wrote:
> 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.

"launcher.<os>.<resource>" makes more sense.

> 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.

Sounds sensible.  For right now I propose using a simple resource class from 
another project we're working one.   This class that supports chained 
resource bundles, where trailing links act as successive, sequential defaults 
for the head link (this may get expanded to a tree impl shortly).  This will 
enable defaulting as described above, although I probably won't get around to 
actually loading the user properties file for a bit.


Now for the hairier issues....

> 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 the other hand, it might be possible to do some gyrations to derive a URL 
for the current openjnlp.jar file - then presumably the other jars could be 
constructed fairly simply from that URL.  This may be a somewhat twisted 
variant of option (3) in the long run.  However, I think it would have the 
added benefit of working when launched from JWS (this idea needs a bit more 
investigation).


The idea of having a jar based OpenJNLP installer is a great one.  One of 
the main reasons we are going with JNLP here is to avoid having to figure out 
on a user by user basis which subset of the app palette is needed, and then 
install it.  This is especially true of our Windows users, since they tend to 
have less of the "well, I'll just figure it out" attitude than our 
Linux/Solaris folks.  I think I may leave it to someone else to tackle the 
implementation, though.


KDE/Gnome integration would sure help encourage people to choose OpenJNLP 
over JavaWS.  Once again, I'm not going to sign up for implementing that just 
yet, though I believe it would be a relatively simple task.

					Chris