JDK-4805849 : JWS should have its own cache file management for downloaded resources
  • Type: Enhancement
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 1.4.2
  • Priority: P4
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: generic
  • CPU: generic
  • Submitted: 2003-01-21
  • Updated: 2003-10-22
  • Resolved: 2003-10-22
Related Reports
Relates :  
Relates :  
Description
In the current cache structure implementation, JWS cache downloaded resources,
such as jnlp file, jar file, etc, using the exact file name downloaded from
the host. For example, if the jnlp link on the host is http://site/app.jnlp,
then the downloaded jnlp file will be stored in the name of app.jnlp.

Such implementation has its limitation. If server is using a servlet to
dynamically return the jnlp file or resource, JWS will not be able to store
it.

There are already several bugs filed due to the limitation of current cache
management. Such as bug 4794040, 4791692.

Here is another bug. For JWS testing, we always use a servlet to return
the jnlp file. This jnlp file is dynamically generated since the j2se tag
will require a specific Java version. This servlet is taking some query
arguments and the jnlp file will be generated based on the value.

Here is one line inside generated jnlp file:
<jnlp spec="1.0+" 
      codebase="http://nasdaq.sfbay:8080/JavawsTest/hellojaws/"
      href="helloservlet.jnlp?TestJRE=1.4.2-beta">

JWS will have the following exception:
General:
An error occurred while launching/running the application.

Title: Java Web Start Test Case -- Hello Java Web Start
Vendor: Sun Microsystems, Inc.
Category: Download Error

Unable to load resource: http://nasdaq.sfbay:8080/JavawsTest/hellojaws/helloservlet.jnlp?TestJRE=1.4.2-beta

Exception:
JNLPException[category: Download Error : Exception: java.io.IOException: Unable to create temp. file for: http://nasdaq.sfbay:8080/JavawsTest/hellojaws/helloservlet.jnlp?TestJRE=1.4.2-beta : LaunchDesc: null ]
	at com.sun.javaws.cache.DownloadProtocol$RetrieveAction.actionDownload(Unknown Source)
	at com.sun.javaws.cache.DownloadProtocol.doDownload(Unknown Source)
	at com.sun.javaws.cache.DownloadProtocol.getLaunchFile(Unknown Source)
	at com.sun.javaws.LaunchDownload.getUpdatedLaunchDesc(Unknown Source)
	at com.sun.javaws.Launcher.downloadResources(Unknown Source)
	at com.sun.javaws.Launcher.handleApplicationDesc(Unknown Source)
	at com.sun.javaws.Launcher.handleLaunchFile(Unknown Source)
	at com.sun.javaws.Launcher.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)


I am suggesting a completely new cache structure. Taking Netscape or IE as
examples, they store downloaded resources (html, image, etc.) using a randomly
generated file name. They maintain a separate file.db database to have a
mapping for the URL link and resources stored on the local disk. I believe
this is the correct approach to handle downloaded resources.

While this bug is filed for JWS, I think it is also appliable to JPI. JPI is
currently indexing downloaded class/jar file. I haven't tried to write a
servlet to return class/jar file dynamically, but I suspect that it will
be the same result.

###@###.### 2003-01-21

Comments
EVALUATION we might consider cache enhancements for tiger. ###@###.### 2003-01-22 The changes to url to cache mapping in tiger make the given test cases no longer reproduce this problem ###@###.### 2003-10-22
22-01-2003