• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Error with Java WebStart Signed Jars on 1.7.0_40

 
Greenhorn
Posts: 1
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 was her plaything! And so was this tiny ad:
New web page for Paul's Rocket Mass Heaters movies
https://coderanch.com/t/785239/web-page-Paul-Rocket-Mass
reply
    Bookmark Topic Watch Topic
  • New Topic