Cryptic jar file names downloaded by Java Webstart in JRE 1.6
We have encountered a few problems in Java Webstart with JRE 1.6
In JRE 1.5, the jar files are getting downloaded onto the client
machine with it's original names.
Example :
Server File Name : acm.jar
Client File Name : RMacm.jar
But in JRE 1.6, the jar files are getting downloaded with improper file names.
Example :
Server File Name : acm.jar
Client File Name : 4fb074cc-66fc7407
Moreover the path itself seems to be invalid.
Example Path :
JRE 1.5 path:
C:\Documents and Settings\Administrator\Application
Data\Sun\Java\Deployment\cache\javaws\https\D17.16.23.11\P443\DMtest\DMwebStart
JRE 1.6 path:
C:\Documents and Settings\Administrator\Application
Data\Sun\Java\Deployment\cache\6.0\12
Due to this, we are facing Classpath problems.
What changes do we have to make to the code, for Java
Webstart to work ?
We are using JBoss 4.0.4 and JDK 1.5 in the Server
On the client machine, we have IE 6 and JRE 1.6.01
Your help would be appreciated.
[1093 byte] By [
ASandesha] at [2007-11-27 3:02:08]
# 1
This has been discussed a lot recently, but
to cut to the chase, an amalgam of recent
relevant comments (mine and Andy's).
Re the cache..
"'No' code should need to rely on knowing the
application path, and Sun states that we cannot
rely on the cache location."
Andy commented..
"If you get the URL of a cached resource, and then
open a connection to that URL, you can access the
contents with getInputStream. Under the covers,
Java 6 will not actually re-download it, but instead
read the contents from the cache. The same code
will work fine with earlier versions of Java Web Start
because the URL will be a file URL to the cache, and
so getInputStream will just be reading the file."
Class.getResource("the/path/to/the/resource");
..pops to mind for this.
And if archives need to be in specific locations..
"Use the JLNP installer element to launch a class that
puts the jar's in a known place, such as a subdirectory
of "user.home". "
# 4
The main reason for reformatting the cache, was the merger of the cache implementations in Java Web Start and Java Plug-in. There is now one cache, and one implementation of downloading and caching code for the two products.
The format and implementation is more similar to what was the previous plugin format, as that was faster and contained more features (cache size limit, ability to run w/o caching all together, and respecting more cache control and http header directives than the webstart implementation.)
The requirement for an undeterminable filename was from the security group. A bug in older versions of IE allowed you to execute a file on the local filesystem that you knew of. ( a jar file is a form of an executable. )
We feel that the cache is only that, a private cache for the java products.
By making this change we recognize that code such as this that assumes it knows the cache's format and contents can no longer work unmodified, and that this will prevent code from being developed that does this in the future.
There are several reasons why code has done this (including some in the JDIC project), but we think there are better mechanisms for achieving the objectives of such code, and are ready to help with what we understand may be a difficult transition for some.
/Andy
