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
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
- relates to
-
JDK-4791692 webstart fails to create jnlp file with 255+ character name on windows
-
- Closed
-
-
JDK-4794040 Splash Screen cache structure has limitation to handle image and application
-
- Closed
-