This content has been marked as final. Show 8 replies
Any jar file that you put the manifest attribute in ... must then be signed.
I believe what you need to do is put the Trusted-Library manifest in your "signed" jar file ...
For applications and applets that are designed to allow unsigned components, the Trusted-Library attribute should be used. No warning dialog will be displayed and an application or applet may load jar files containing untrusted classes or resources. This attribute prevents signed components in an application or applet from being re-purposed with unsigned components.
All classes and resources in a jar file containing this manifest attribute must be signed.
In a mixed code application or applet, all signed classes and resources must be included in jar files that contain the Trusted-Library attribute.
All trusted library jars are loaded into a separate dedicated class loader which is unique to the application or applet. The trusted library code components cannot be replaced and trusted library classes and resources are isolated from all untrusted components.
I am facing a similar problem as posted in this thread. The applet is present in a signed jar which loads the classes from the 3rd party lib jar which is unsigned. In order to avoid the security warning, I have added "Trusted-Library: true" to the manifest file of the signed applet jar. After this, when the applet runs and tries to load the classes from the unsigned 3rd party jar, I see NoClassDefFoundError in the java console.
Does this exception relate to the different class loaders used? Any clues?
We are also seeing the same issue. The problem with the Trusted-Library workaround (as described in http://java.sun.com/javase/6/docs/technotes/guides/jweb/mixed_code.html) is that it doesn't appear to handle the case where our signed jar classes need to call into unsigned jar classes. Adding the Trusted-Library attribute to our signed jar causes it to be loaded in a different classloader than the unsigned 3rd party jar(s), so of course NoClassDefFound errors will occur when trying to load these classes. I would think this is a very common case for most Java applet developers. Furthermore, Sun also seems to say that the workaround can be employed by target end users/administrators, who would simply add the attribute to existing production signed jar files.
Does anyone know if there any workaround for the mixed-signed case that will allow signed jars calling into unsigned 3rd party jars? I do not want to start adding fancy classloader switching code to my applets.
in the http://download.oracle.com/javase/6/docs/technotes/guides/jweb/mixed_code.html
Code in a jar file that is to be marked with the Trusted-Library manifest attribute may need to be modified slightly if it uses calls that are class loader dependent, such as the single parameter version of Class.forName(), Class.getResource(), and Class.getResourceAsStream(), some variants of java.util.ResourceBundle.getBundle(), and any other methods which operate relative to their immediate caller's defining loader. Changes only need to be made if the requested class or resource might be found in a jar file which is not a Trusted-Library (and is therefore loaded by the normal Web Start or applet class loader).
and the problem is how to modify?
for example, i need to init log4j in a applet main class, but log4j.jar is unsigned, how to change the following line in applet main?
static Logger logger = Logger.getLogger(ArcTest.class.getName());
hope there is some guy who can figure out the solution,
this problem is very very disgusting!!!