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