Java Web Start

[Roedy Green]

I could not find this is a casual perusal, so today I will have to
read the docs through.

What I am after:

1. ways of passing info from the JNLP file to the Weblet to configure
it.

2. ways to find a good place to store files on the client where they
won't disappear.

3. how to configure separate instance of the app that may use the same
jar, but that are configured differently and use different application
files.

 

[Christophe Vanfleteren]

I could not find this is a casual perusal, so today I will have to
read the docs through.

What I am after:

1. ways of passing info from the JNLP file to the Weblet to configure
it.

You can set properties using <property name="..." value="...."/> in the

2. ways to find a good place to store files on the client where they
won't disappear.

You'll have to use the javax.jnlp.FileSaveService for saving files.
There's more info on special jnlp services at http://java.sun.com/products
javawebstart/docs/javadoc/index.html

 

[Roedy Green]

1. ways of passing info from the JNLP file to the Weblet to configure
it.

You can put info in the jar as a resource or use the resource/property
section of the JNLP file to set a system property.

2. ways to find a good place to store files on the client where they
won't disappear.

Does not appear to exist. You have to ask the client. There is no
natural place. The Persistence services Muffins are obscenely Mickey
Mouse which you would have to use to remember that directory.

3. how to configure separate instance of the app that may use the same
jar, but that are configured differently and use different application
files.

What it appears to do is download different jars and different JNLPs
and keep them entirely separate. This is a good thing.


This files business is not properly thought through. A program should
get a little persistent directory to play in and that directory should
be optionally deleted if the app is uninstalled. A JWS program should
wake up with that directory as the current directory.

 

[Ike]

I could not find this is a casual perusal, so today I will have to
read the docs through. disappear.

3. how to configure separate instance of the app that may use the same
jar, but that are configured differently and use different application
files.

Make separate jar files, one each with the inidividual main classes you will
need for each different application and it's own manifest, then, one main
one that they all use, which has all the files. LOL....hey, arent we
getting back to dll's ? //Ike

 

[Roedy Green]

Make separate jar files, one each with the inidividual main classes you will
need for each different application and it's own manifest, then, one main
one that they all use, which has all the files. LOL....hey, arent we
getting back to dll's ? //Ike

I have written a JWS program called The Replicator for distributing a
set of files and keeping them up to date. It is possible that quite
independent groups might deploy it for distributing unrelated files.
A user might then be using the program for two independent purposes.

I discovered what would happen is the the user would get a copy of the
jar from who different websites. Even though the jar would be
identical, it would have a different JNLP file, and would be
downloaded and maintained twice.

Unfortunately, a JWS program does not get assigned a little directory
to play in. Using the preferences system, I can ask the user for one,
and store it. However, the preferences scheme works off class name,
so both instances would use the same preferences key unless I do
something to keep them separate.

There are JWS preferences called Muffins which looks so Mickey Mouse I
did not investigate them fully.

 

[Dale King]

Does not appear to exist. You have to ask the client. There is no
natural place. The Persistence services Muffins are obscenely Mickey
Mouse which you would have to use to remember that directory.

It's not clear what you are after here. You seem to want to be able to
access the files from outside of the JNLP app. The persistance service was
not designed for this.

What it appears to do is download different jars and different JNLPs
and keep them entirely separate. This is a good thing.

You can package the common resources into a component extension that is
accessed by the different apps. Theses resources are then managed as a
single entity. Most of the the documentation does not talk about extension
descriptors. You have to go to the JNLP spec to read about them. See section
3.7.1 of the spec for defining a JNLP file for a component extension and
section 4.7 for using it.

This files business is not properly thought through. A program should
get a little persistent directory to play in and that directory should
be optionally deleted if the app is uninstalled. A JWS program should
wake up with that directory as the current directory.

That would be a big security hole though, so it should require getting
permissions to do that. If you get permissions you can do that yourself.

My big issue is that I can only download and access things in Jar files. But
jar files only give you serial access to the contents. I might want a large
file to be part of my app and to be able to access that file using random
access. JWS does not allow that without getting all permissions.

 

[Dale King]

I have written a JWS program called The Replicator for distributing a
set of files and keeping them up to date. It is possible that quite
independent groups might deploy it for distributing unrelated files.
A user might then be using the program for two independent purposes.

I discovered what would happen is the the user would get a copy of the
jar from who different websites. Even though the jar would be
identical, it would have a different JNLP file, and would be
downloaded and maintained twice.

See component extensions for avoiding this.

Unfortunately, a JWS program does not get assigned a little directory
to play in. Using the preferences system, I can ask the user for one,
and store it. However, the preferences scheme works off class name,
so both instances would use the same preferences key unless I do
something to keep them separate.

It sounds like you want access to files outside of WebStart in which case
you will never get there inside the sandbox. You have to go outside of the
sandbox because you are doing things that are potentially unsecure. Once you
are out of the sandbox, the question of what WebStart provides is moot as
you have all of J2SE at your disposal.

There are JWS preferences called Muffins which looks so Mickey Mouse I
did not investigate them fully.

It is not Mickey Mouse, it is just designed for an entirely different
purpose. It's primary purpose is for remembering user preferences.

 

[Roedy Green]

It is not Mickey Mouse:

1. the cutesy name Muffins.

2. numbered, not named.

3. the clumsy renaming rules to get uniqueness.

 

[Dale King]

1. the cutesy name Muffins.

What cutesy name Muffins? The word Muffin appears nowhere in the JNLP spec.
The name muffins was coined to be like HTML cookies, but the name is not
official. The official title is PersistenceService. Does that sound official
enough for you?

2. numbered, not named.

What numbering? You get multiple files that are indexed in your program by a
URL not a number.

3. the clumsy renaming rules to get uniqueness.

I believe you are referring to how the JNLP client stores information for
the PersistenceService. That is an implementation detail. A JNLP client can
choose to store it however it likes. This is not covered by the spec.

Once again I think you are trying to use them for something that they were
not designed for. That does not make them Mickey Mouse. It simply means that
they were designed for a different set of requirements.

The PersistenceService was designed for an app to store information for its
own use for later incarnations. It was not designed as a way to store
information for use outside of JNLP.