JWS Hanging when updated jar available

Question

Hi,
When I make an updated JAR file available, it gets downloaded and verified correctly (it's signed), but then nothing. The progress dialogue simply says that scanning has reached 100%. There have been a couple of threads along these lines, but nothing that seems to jump out as a solution. Here are the details:
I have an application that I am deploying, as described by this JNLP file:
<?xml version="1.0" encoding="ANSI"?>
<jnlp spec="1.0+" href="ourapp_main.jnlp" codebase="http://myMachineName/ourapp">
  <information>
    <title>Application Titlet</title>
    <vendor>Meridian Informatics</vendor>
    <homepage href="http://meridianinfo.com" />
    <description>Our app</description>
    <description kind="one-line">Our app</description>
    <description kind="tooltip">Our app</description>
    <description kind="short">Our app</description>
    <icon href="http://myMachineName/ourapp/images/icon.gif" version="" width="" height="" depth="" size="" />
    <offline-allowed />
  </information>
  <resources>
    <j2se version="1.3+" />
    <jar href="ourapp_main.jar" main="false" download="eager" />
    <nativelib href="win32printerdll.jar" download="eager" />
    <extension href="activation.jnlp" name="activation" />
    <extension href="borland.jnlp" name="borland" />
    <extension href="collections.jnlp" name="collections" />
    <extension href="design_pro.jnlp" name="design_pro" />
    <extension href="ourapp.jnlp" name="ourapp" />
    <extension href="ibmftp.jnlp" name="ibmftp" />
    <extension href="framework.jnlp" name="framework" />
    <extension href="mail.jnlp" name="mail" />
    <extension href="xreport_pro.jnlp" name="xreport_pro" />
    <extension href="xtools.jnlp" name="xtools" />
  </resources>
  <security>
    <all-permissions />
  </security>
  <application-desc main-class="com.meridianinfo.ourapp.twotier.MainApp" />
</jnlp>And here's a JNLP file for one of the extensions (all extension JNLP files were copied from an original and the relevant names changed):
<?xml version="1.0" encoding="ANSI"?>
<!--  created on Tue Aug 28 13:18:27 GMT+11:00 2001  --><!--  created by fitzpatk on Windows 2000  --><!--  1.3.0  -->
<jnlp codebase="http://myMachineName/ourapp" spec="1.0+" href="ibmftp.jnlp">
  <information>
    <title>Desktop for Ecommdirect</title>
    <vendor>Meridian Informatics</vendor>
    <homepage href="http://meridianinfo.com" />
    <offline-allowed />
    <icon kind="default" href="http://myMachineName/ourapp/images/icon.gif" />
  </information>
  <resources>
    <jar href="ibmftp.jar" main="false" download="eager" />
  </resources>
  <component-desc />
  <security>
    <all-permissions />
  </security>
</jnlp>In versions of JWS prior to the latest, all the JNLP files would be downloaded, but then processing would stop (i.e. no jar files would be downloaded).
When using the latest version of JWS, launching an application for the first time works fine - everything gets downloaded correctly, installed, and the application launched. As long as there are no updates, this continues to work.
If I update one of the jar files, it is downloaded and scanned, but the application never starts. The dialogue stating that scanning has reached 100% remains on screen. There is nothing untoward in the log file or in the console. If I hit Cancel at this point, and try to launch the application again, everthing works (of course, there is nolonger an update to download at this point).
If I update two or more jar files (but not all!), I have to repeat the previous procedure for every updated jar file, before the application will launch.
If I update all of the jar files, it works as expected - everything is downloaded and installed and the application is started.
BTW: I am "updating" the jar files by resigning them (using jarsigner).
I am using Win NT and Win 2K, JRE's 1.3.1 and 1.3.0_01.
This looks like a bug to me, but before I log it as such, I'd appreciate hearing your thoughts/comments. Maybe there is something missing from my JNLP files, or some combination of software that is likely to cause this?
All comments appreciated.
Kieran

Answer 1

There have been a couple
of threads along these lines, but nothing that seems
to jump out as a solution.Yep.
My strategy is brute force, born out of cluelessness, and is either
1. nuke .javaws/cache and retry
or if that doesn't help get really angry and
2. nuke the whole Java Web Start installation directory (and please make sure that not a single .dll survived eg due to IE having some instance slurped in), reinstall Web Start and retry
and if that does not help we go into scapegoat location mode and do
3. It must be the bloody JRE, thus try again with 1.3.1, 1.3.1_01, 1.4 and whatever JRE you get your hands on, try also alternative vendors like IBM or Blackdown
the adventureous now might do
4. sign that incomprehensible license agreement, download the Web Start sources and fix the problem yourself
but if you have not enough time or skills on your hand then finally give up and try
5. It is a Web Start bug. Let's submit it as bug and wait for 1.1
Not too subtle, eh? :-)
But there are reasons for this.
installation of new versions might end in a mess
No. 2 is motivated by the fact that deinstallations of old Web Start versions and installations of new Web Start versions might lead to a mess.
Ideally Web Start would work afterwards such installations without problems, and even better, the old cache would be left intact, so that not everything needs to get downloaded again.
I had two cases (me playing with 1.01 and 1.01_01, and a colleague playing with 1.01something and trying out the 1.4 JDK beta, where Web Start is a part of the JDK) where this led to a hang of that kind what you described.
The installation guide
http://java.sun.com/products/javawebstart/docs/installguide.html
hints as well that things might go wrong.
cache corruption, insufficient change detection
No. 1 is rooted in the observation that Web Start's update mechanism does not work as expected.
Ideally, when we launch an app, the Web Start client should find out about the main jnlp file and the sub jnlp files and jar files that are used by it. It should detect changes in all those items and download if they changed.
BTW: I am "updating" the jar files by resigning them
(using jarsigner).But what changes does it detect?
- does it just look if something with the same name is already in the cache?
- does it look at the timestamps of the cache contents and compare that to the timestamps of the versions on the server?
- does it compare content differences (eg by calculating hashes like md5 or SHA-1)?
My impression that it does only the first.
I very often have to empty the whole Web Start cache on the client, when I'm changing/updating jars and jnlps on the server.
more fun
No.3 is justified by experience. I had many surprises here.
Regards,
Marc