aspose file tools*
The moose likes JNLP and Web Start and the fly likes Error with Java WebStart Signed Jars on 1.7.0_40 Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JNLP and Web Start
Bookmark "Error with Java WebStart Signed Jars on 1.7.0_40" Watch "Error with Java WebStart Signed Jars on 1.7.0_40" New topic
Author

Error with Java WebStart Signed Jars on 1.7.0_40

Nayan Son
Greenhorn

Joined: Feb 28, 2014
Posts: 1
We are aware of the issue with jar softlinker
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6967414
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6805618

and have used following class (found on web and modified to take care of JAVA 7 as well.)



When we launch the application with JRE6 it works fine. But the problem is with JRE7. When the application is launched with JRE7 we get below exception in the log. From the exception we know that the jars are not hard referenced and that the user can have problems if the jars get garbage collected. We have a release next week and need to find a work around for this issue.

java.lang.NoSuchMethodException: com.sun.deploy.cache.CachedJarFile.getSigners()
at java.lang.Class.getDeclaredMethod(Unknown Source)
at com.tullib.ui.main.JarSignersHardLinker.callNoArgMethod(JarSignersHardLinker.java:96)
at com.tullib.ui.main.JarSignersHardLinker.makeHardSignersRef(JarSignersHardLinker.java:45)
at com.tullib.ui.main.JarSignersHardLinker$1.run(JarSignersHardLinker.java:262)
at java.lang.Thread.run(Unknown Source)
java.lang.NoSuchFieldException: signersRef
at java.lang.Class.getDeclaredField(Unknown Source)
at com.tullib.ui.main.JarSignersHardLinker.makeHardLink(JarSignersHardLinker.java:69)
at com.tullib.ui.main.JarSignersHardLinker.makeHardSignersRef(JarSignersHardLinker.java:46)
at com.tullib.ui.main.JarSignersHardLinker$1.run(JarSignersHardLinker.java:262)
at java.lang.Thread.run(Unknown Source)
This exception is repeated 52 times (for all the JAR's).

We have made sure that all the 52 jars/files (except the JNLP itself) are signed properly and that the java cache is cleard before the application is launched.

JAVA version used is JDK 7u40 on windows machine.

Options tried are:
Removing the jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024 from java.securites file.
Checking the jar signer certificate. Signer certificate uses SHA1withRSA as signing algorithm.


Note:
THE SOURCE CODE IS COMPILED IN JAVA 5u11 AND RUN IN JAVA 7u40
We have observed one more difference. With JRE6, when we run the same piece of code, it first loades JAVAWS.jar, Deploy.jar and plugin .jar from java/jre6/lib path but with JRE7 these jars are not loaded.


This has been tried in both 64 and 32 bits java version with no luck.

Any help here is really appreciated.
Jim Colquist
Greenhorn

Joined: Aug 21, 2014
Posts: 1

I've been able to modify the original "JarSignersHardLinker" code that worked on Java 1.6 to also work on Java 1.7. The original code failed on Java 1.7 for a few reasons:

1) The mechanism for getting the list of jar files loaded by the JNLP in the original JarSignersHardLinker used the method:

Thread.currentThread().getContextClassLoader().getResources("META-INF/MANIFEST.MF")

However, in later versions of java 1.7 (I was using 1.7_45), when you access the Enumeration returned by that method, java throws up a security dialog telling you that you are accessing mixed signed/unsigned code. This dialog forces the user to select "Unblock" to allow the application to continue. This is true EVEN if all of your jars are signed! See this link describing that issue: https://community.oracle.com/thread/2593279

To work around this, we need to get the list of jar URLs in a different way. Since we know that we are running from JNLP, we know that the class loader is of type JNLPClassLoader. We can use methods on that class to get the jar list available at:

(JNLPClassLoader) (Thread.currentThread().getContextClassLoader()).getLaunchDesc().getResources().getLocalJarDescs()

The code uses reflection to call that method to get the jar list. This does not trigger the security dialog. Refer to this link (https://code.google.com/p/flyway/issues/detail?id=287) for where I got the idea on how to do this.

2) The structure of class "com.sun.deploy.cache.CachedJarFile" is changed in java 1.7. Under java 1.6, the original JarSignersHardLinker code would preserve the fields "signersRef", "signerMapRef" and "codeSourceCacheRef" by creating hard links to them. These fields no longer exist in the Java 1.7 version of CachedJarFile. Instead, under java 1.7 all of the signing data is consolidated in field "signingDataRef". So the updated linker code, in "makeHardSignersRef" only make a hard link to "signingDataRef" field.

The code has gone through a full cycle of testing without seeing the garbage collection issue with signed jars under java 1.7_45 and Java Web Start. I'm posting my code in case anyone else is struggling with the same issue.

Note that this code ONLY works on 1.7...it is NOT backwards compatible with 1.6. In our system, I've created a simple branch that calls the older version if we are running on java 1.6, and this new updated code if on java 1.7.

Here is the code:

 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Error with Java WebStart Signed Jars on 1.7.0_40