I have a web application (hudson.war --- see http://hudson.dev.java.net/). Since a .war file is really just a .jar file, my hudson.war contains enough stuff (like Main-Class in META-INF/MANIFEST.MF) to make it launchable as a jar by running "java -jar hudson.war". This is desirable to make this web application easily installable. This war file is signed, too.
When I tried to run this hudson.war from JNLP, I got an error from Java web start claiming that this war file is not signed. Since it needs unlimited access to the system, it fails to launch my program.
After downloading the web start source code and tracing the code, I found that com.sun.deploy.cache.CacheEntry is not reading the manifest file of my war file at all. In fact, this class works differently between jar files and non-jar files. hudson.war was considered as a non-jar resource, and hence it fails the test in line 652, so the manifest entry is simply ignored.
Later, after all the files are downloaded, com.sun.javaws.LaunchDownload checks all the JARDesc instances of the JNLP file. Since my JNLP file reads as follows, the system picks up CacheEntry and tries to pick up code signers and certificates. But the CacheEntry didn't read my manifest, so it returns nothing, and hence the processing with the UI saying "resource not signed":
<resources>
<j2se version="1.5+"/>
<jar href="https://hudson.dev.java.net/files/documents/2402/52759/hudson.war"/>
</resources>
The essence of the problem is that there's no consistent handling as to "what is a jar file". Either the caller of the CacheEntry class should supply that information (whoever requesting to download hudson.war should know that it's doing so because this is a JARDesc), or the CacheEntry should be modified to scan manifest later when it turns out that a particular resource is used as a jar file.
I should also point out that generally speaking relying on the extension to decide the content type is not a good idea.
For example, in JAX-WS, we expose the web service endpoints on a servlet container, and clients need a dedicated java program to talk to it. So we are talking about perhaps responding to requests like "http://foobar/myWebService/?jar" to return a jar file that contains what the client needs. (?jar goes nicely with the industry convention of ?wsdl, ?xsd etc that it already implements.)
This bug makes it impossible for me to use that resource directly in JNLP descriptor.
When I tried to run this hudson.war from JNLP, I got an error from Java web start claiming that this war file is not signed. Since it needs unlimited access to the system, it fails to launch my program.
After downloading the web start source code and tracing the code, I found that com.sun.deploy.cache.CacheEntry is not reading the manifest file of my war file at all. In fact, this class works differently between jar files and non-jar files. hudson.war was considered as a non-jar resource, and hence it fails the test in line 652, so the manifest entry is simply ignored.
Later, after all the files are downloaded, com.sun.javaws.LaunchDownload checks all the JARDesc instances of the JNLP file. Since my JNLP file reads as follows, the system picks up CacheEntry and tries to pick up code signers and certificates. But the CacheEntry didn't read my manifest, so it returns nothing, and hence the processing with the UI saying "resource not signed":
<resources>
<j2se version="1.5+"/>
<jar href="https://hudson.dev.java.net/files/documents/2402/52759/hudson.war"/>
</resources>
The essence of the problem is that there's no consistent handling as to "what is a jar file". Either the caller of the CacheEntry class should supply that information (whoever requesting to download hudson.war should know that it's doing so because this is a JARDesc), or the CacheEntry should be modified to scan manifest later when it turns out that a particular resource is used as a jar file.
I should also point out that generally speaking relying on the extension to decide the content type is not a good idea.
For example, in JAX-WS, we expose the web service endpoints on a servlet container, and clients need a dedicated java program to talk to it. So we are talking about perhaps responding to requests like "http://foobar/myWebService/?jar" to return a jar file that contains what the client needs. (?jar goes nicely with the industry convention of ?wsdl, ?xsd etc that it already implements.)
This bug makes it impossible for me to use that resource directly in JNLP descriptor.
- duplicates
-
JDK-6519657 Certificates of signed JAR files without file ending ".jar" are ignored
-
- Closed
-