Forum Stats

  • 3,759,060 Users
  • 2,251,495 Discussions


How to avoid SecurityException with JRE 1.6.0_19 update

843798 Member Posts: 24,864

I have an applet which is present in a signed jar. This applet uses another jar file which is unsigned.
On launching the applet I get the Mixed code warning which I want to avoid.

To solve this issue, I added "Trusted-Library: true" to the unsigned jar which is being used by my applet.

But, it still throws SecurityException. I tried this with JRE update 20 as well but problem persists.

Can someone please help me with this? How to avoid getting the Warning message when I have to use an unsigned jar.




  • 793415
    793415 Member Posts: 7,279
    What is the exact (copy/pasted) exception you are seeing? Does it point to the signed Jar, or the unsigned Jar?
  • 843798
    843798 Member Posts: 24,864
    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 ...

    Trusted-Library Attribute

    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.
  • 843798
    843798 Member Posts: 24,864
    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?
  • 843798
    843798 Member Posts: 24,864
    edited May 6, 2010 10:47AM
    I have the same issues, just with a configuration file from an unsigned jar. See:

    What is it we are missing?

    Edited by: H.Dohlmann on May 6, 2010 7:47 AM
  • 843798
    843798 Member Posts: 24,864
    We are also seeing the same issue. The problem with the Trusted-Library workaround (as described in 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.
  • 830287
    830287 Member Posts: 1
    in the

    it says,

    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!!!
  • PhHein
    PhHein Member, Moderator Posts: 7,167 Silver Trophy
    Please don't post in threads that are long dead and don't hijack other threads. When you have a question, start your own topic. Feel free to provide a link to an old post that may be relevant to your problem.

    I'm locking this thread now.
  • 1031171
    1031171 Member Posts: 1

    This question is still valid and it's in the top 5 google searchs for trusted-library issues.

    If there was a satifactory answer anywhere it's not on these forums perhaps we could bump this to get a fresh answer to the old problem?

This discussion has been closed.