Java Web Start and program updates

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I just managed to set up my program to work with Javaws. It would be
good to have a simpler tutorial for this purpose, I have to say.
Anyway, it works now in Linux and Windows (I use a native lib), Mac
coming up soon.

One thing that isn’t clear to me yet is how to do automatic update and
versioning. I heard that javaws takes care of that, but I don’t
understand how.

So the simple question is: what do I have to do if I release a new
version and want the javaws users to get it?

jnlp file at http://tcl.sfs.uni-tuebingen.de/MonaSearch/MonaSearch.jnlp

TIA, H.
- --
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAki7xdMACgkQBGFP0CTku6No8gCbB2EdiJQIapcvC6dWWH+fGUY6
ssEAoL9mCJCR1MovpjN+qm8MRd7Fh5NA
=CZKl
-----END PGP SIGNATURE-----

 

[Andrew Thompson]

I just managed to set up my program to work with Javaws.  
Congrats..

One thing that isn’t clear to me yet is how to do automatic update and
versioning.  I heard that javaws takes care of that, but I don’t
understand how.

Since your JNLP specifies <offline-allowed />, the
client should check if the Jar's on the server are
newer than the cached versions, but if the internet
or site is not available at that moment, go ahead
with the launch anyway. Otherwise if the server
Jar's are newer*, it will update them.

Versioning using the JNLP servlet is a lot more subtle
and powerful, but I have not needed, nor dealt with
that much.

* Note that if you do a couple of quick updates to a
live site in a different timezone, JWS can be fooled
into thinking the remote Jar's are actually older.

 

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sabine Dinis Blochberger schreef:

Here's an older article that explains some concepts (scroll down for the
versioning part)
<http://www.ibm.com/developerworks/java/library/j-webstart/>
Thanks.


It's sufficient to upload the newer .jar files. There might be problems
when the server has a different timezone setting (I notice this
sometimes with FTP).

So it is simply based on file modification dates, I suppose.

In my experience, it is necessary to re-open the application for it to
actually download the updates, so they might only be available at the
2nd restart of the application.

This probably has to do with the ‘download’ attibute to the jar element.
I suppose download="eager" will make sure you don’t have to restart.

The valid nntp signature separator is dash dash space.

I know, but PGP-signing interferes with this, unfortunately. There is a
bug about this at Mozilla, but I can’t find it.

Thanks all, H.
- --
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAki73YwACgkQBGFP0CTku6NdowCfbK1AL51s+dDO3R2+JdU8ZynU
TDQAn3BqgIEtkzkwGIvJ73ZNlt1WwLMJ
=Thpm
-----END PGP SIGNATURE-----

 

[Andrew Thompson]

This probably has to do with the ‘download’ attibute to the jar element.
 I suppose download="eager" will make sure you don’t have to restart.

You suppose wrong. eager/lazy downloads control
whether resources are downloaded automatically, or
on 1st request. Main jar's and natives must be eager.

 

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Thompson schreef:

You suppose wrong. eager/lazy downloads control
whether resources are downloaded automatically, or
on 1st request. Main jar's and natives must be eager.

You’re right, it is the check attribute of the update element which
controls this:

‘ check attribute: The check attribute indicates the preference for when
the JNLP Client should check for updates, and can have one of the three
values: "always", "timeout", and "background"

A value of "always" means to always check for updates before launching
the application.

A value of "timeout" (default) means to check for updates until timeout
before launching the application. If the update check is not completed
before the timeout, the application is launched, and the update check
will continue in the background.

A value of "background" means to launch the application while checking
for updates in the background. ’

I suppose that if updates are found in the background but the app is
already running, it will download them and only use them the next time.

H.
- --
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAki8I2wACgkQBGFP0CTku6PFnwCgwKfadhYItGhjOOxIQM7XeZLh
jfsAoLK87jHojO6m4Woh6tro0z6O9c45
=GkNi
-----END PGP SIGNATURE-----

 

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Thompson schreef:

Since your JNLP specifies <offline-allowed />, the
client should check if the Jar's on the server are
newer than the cached versions, but if the internet
or site is not available at that moment, go ahead
with the launch anyway. Otherwise if the server
Jar's are newer*, it will update them.

This doesn’t seem to work properly. I have an Apache server on Linux. I
replaced a nativelib jar with a newer one, but the application was still
using the old one. After much hassle (deleting the application on the
client etc.), it then worked, but I had hoped it would be more automagical.

What could be the reason? Any advice?

H.
- --
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAki+TXUACgkQBGFP0CTku6PN1ACgjx0ut3osewfyW3LwiXdq9vkA
QUcAnirGdX6++o8yE/ehfxahhb9DMgsE
=58mL
-----END PGP SIGNATURE-----

 

[Andrew Thompson]

....
This doesn’t seem to work properly.   ....
What could be the reason?

Timezone problems?

.. Any advice?

Since it has already been mentioned twice I would
make sure you both rule out, and mention how you did
that, timezone problems.

 

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Thompson schreef:

Timezone problems?


Since it has already been mentioned twice I would
make sure you both rule out, and mention how you did
that, timezone problems.

I doubt it will be timezone problems if all three computers involved in
the testing are in the same city. Indeed both the server and my machine
give the same output for ‘date’.

Can the problem lie with the client’s timezone settings?

H.
- --
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAki+aS8ACgkQBGFP0CTku6N5CwCfea9iPVE4W3rtyjlwzJy3kgIi
7kAAn3+w6jJNCoyDSYXBGLAMPujimh7l
=8JwX
-----END PGP SIGNATURE-----

 

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sabine Dinis Blochberger schreef:

Try <update="background"update check="background" policy="always"/>?
It's the only one that worked for our application (with at least one
restart of it).

You mean

<update check="background" policy="always"/>

Indeed, that will need a restart each time. I’d rather avoid that.

It’s strange though, that check="timeout" wouldn’t suffice, since I am
sure the server is quite fast and it is even in the same network as the
machines I have been testing with.

H.
- --
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAki+af0ACgkQBGFP0CTku6O6KwCeIkisT1KY6gV7FxOO8sQ7GtQh
Hv8AoIF5ta8DQGmTNVcjbanGcjQRbjkr
=u4kH
-----END PGP SIGNATURE-----

 

[Andrew Thompson]

Can the problem lie with the client’s timezone settings?

Yes, I think so. Also, confirm that each system is
checking the time (system clock) against a remote
source (I would imagine most machines connected to
the internet these days, do that already).

 

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Thompson schreef:

Yes, I think so. Also, confirm that each system is
checking the time (system clock) against a remote
source (I would imagine most machines connected to
the internet these days, do that already).

Thanks all, I think probably I just didn’t start the app twice. Let’s
look how things go in the future.

Cheers, H.
- --
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAki+hR8ACgkQBGFP0CTku6NTFwCfQYkPbW1KgiwYtBl60ijshfFX
sHAAn1z1DEf8QE+7I2oKTgarHqh2sLpv
=l+P+
-----END PGP SIGNATURE-----

 

[Roedy Green]

One thing that isn’t clear to me yet is how to do automatic update and
versioning. I heard that javaws takes care of that, but I don’t
understand how.

It works for me, but I'm not sure how it does it.

Perhaps the mystery could be solved with some Wiresharking.
See http://mindprod.com/jgloss/wireshark.html

I think it works like this:

1. the browser reads the JNLP file your link points to.

2. the browser hands it off to Javaws.exe

3. javaws.exe looks in that JNLP file for a link to the master JNLP
file.

3. Javawes.exe looks in the cache and decides by some mysterious
process if the jar is out of date. How could it know? It knows
neither the date of the JNLP file nor the date of the jar. All it
knows is the dates of the two JNLP files were downloaded and if they
are identical.

Logically I could see it being smart enough to download only when you
change the version number in the master JNLP file, but I think I have
seen it download when the jar file changed.

Perhaps it somehow finds the SIZE of the jar file and reloads it if
has changed.

Does HEAD tell you the size? Perhaps it does a GET on the jar and
aborts if the size is the same.

If you run a JWS server, this all can be handled more elegantly.

 

[Roedy Green]

Yes, I think so. Also, confirm that each system is
checking the time (system clock) against a remote
source (I would imagine most machines connected to
the internet these days, do that already).

One server may use UTC as local time and the other PDT. You can
probably find out what they are up to by logging in with FTP.

 

[Roedy Green]

I think it works like this:

1. the browser reads the JNLP file your link points to.

2. the browser hands it off to Javaws.exe

3. javaws.exe looks in that JNLP file for a link to the master JNLP
file.

3. Javawes.exe looks in the cache and decides by some mysterious
process if the jar is out of date. How could it know? It knows
neither the date of the JNLP file nor the date of the jar. All it
knows is the dates of the two JNLP files were downloaded and if they
are identical.

I just watched the process with Wireshark. It downloads the jar EVERY
time.

this is with:

<update check="always" policy="always" />
<jar href="replicator.jar" main="true" download="eager" />

 

[Roedy Green]

Intersting. How are your settings on caching?

I didn't change any settings. Where can you do that? I don't see
anything in the Control Panel Java.