JDK-6566071 : Java Web Start doesn't check time stamp of nested JNLP files
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 6u1
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2007-06-05
  • Updated: 2010-04-04
  • Resolved: 2008-03-09
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6u10Resolved
Related Reports
Duplicate :  
Description
Java Web Start in JDK6 doesn't check time stamp of nested JNLP files. This is regression, since it works fine in JDK 5.

For example, if the application JNLP file looks like this:

<jnlp ...>
   <resource>
      <jar href="my-app.jar" main="true"/>
      <extension href="http://some.where.com/my-library.jnlp"/>
   </resource>
   ...
</jnlp>

the application JNLP file and the "some.where.com/my-library.jnlp" file will be cached. If the "some.where.com/my-library.jnlp" file is subsequently updated, the cache will not be re-validated, and the old version of the JNLP file will be used. This can cause the application to fail if the resources referred to by the old JNLP file are modified or removed.

We have set up a test case using Java 3D that you can use to diagnose the problem. You will need to copy the following .zip file to your server, unzip it, and modify the codebase in the four JNLP files as described below. Here is the pointer to the zip bundle:

http://download.java.net/media/java3d/webstart/prototype/cache-bug.zip

The directory structure is:

cache-bug/
  early-access/
    java3d-1.5.0.jnlp     -- Java 3D 1.5.0 library JNLP file
    java3d-1.5.1.jnlp     -- Java 3D 1.5.1 library JNLP file
    java3d-latest.jnlp    -- actual JNLP extension file, a copy of 1.5.0 or 1.5.1
    use-1.5.0             -- script to copy 1.5.0 to latest
    use-1.5.1             -- script to copy 1.5.1 to latest
    ...

  test/
    QueryProperties.jnlp    -- application JNLP file
    HelloUniverse.jnlp      -- another application JNLP file
    ...

After you have modified the codebase in QueryProperties.jnlp java3d-1.5.0.jnlp and java3d-1.5.1.jnlp (and optionally HelloUniverse.jnlp), you should do the following:

cd .../early-access
./use-1.5.0             # this will copy 1.5.0 to latest

javaws http://your.server.com/your-base-dir/cache-bug/test/QueryProperties.jnlp

You will see the following line at the top of the scrollable text window:

"j3d.version = 1.5.0 fcs (build8)"

If you then run the command "./use-1.5.1" from the early-access directory, which will update the java3d-latest.jnlp file, and rerun the QueryProperties demo, you should see the following:

"j3d.version = 1.5.1-beta2 (build5) 31 May 2007 14:01:07 PDT"

This works on JDK 5. You get the old version on JDK 6.

Comments
SUGGESTED FIX see CR 6668033 for details
09-03-2008

SUGGESTED FIX As described in the evaluation, but only do the download in DownloadEngine.getResourceCacheEntry, if the Cache is enabled ! A true proper fix would be to re-think the DownloadEngine API, so a user just can get a resource without considering the cache at all, by just passing this 'doDownload' flag. An extra set of CacheUtil function may map the ressource to the actual CacheEntry, for admin/maintenance purposes .. This would ease the whole resource callee code, since no more hassles like: IF (Cache.isEnabled()) THEN get it this way and think about the update ELSE get it another way .. would be necessary.
02-03-2008

EVALUATION JNLP Resource update - DownloadEngine.getResourceCacheEntry() - impact if doDownload==true and !versioned for - getCachedFile() - getResource() - getCachedSize() - getCachedJarFile() - getShortcutImage() - using isUpdateAvailable(..,clientSidePack200=true), - which does a net lookup for a newer file, if no version is given! - downloads ressource if (!Cache.isCacheEnabled() && doDownload) - DownloadEngine.isUpdateAvailable() - respects Cache.isCacheEnabled() - verifies DeployOfflineManager first before returning true ! - DeployOfflineManager.isGlobalOffline() -> throw FailedDownloadException - DownloadEngine.updateCheckDoneList - add missing synchronized(syncObject) {} - Impact: - all ressources are now properly checked for updates, if online && not versioned. - no more explicit update code must be made implemented
01-03-2008

SUGGESTED FIX http://web-east.east/deployment/www/webrevs/ngthomas/6566071/6u4/webrev/
08-06-2007

WORK AROUND remove nested jnlp file via cache viewer
08-06-2007

EVALUATION bug in java web start.
08-06-2007