4

For an java web application, I got this error when using JRE 1.6.0_22

java.lang.SecurityException: class "org.apache.log4j.Logger" does not match trust level of other classes in the same package

However, it works fine when using JRE 1.6.0_13.

I searched in Google, and find the there is a security enhancement since update 19.

And for this exception, it says,

The following two SecurityExceptions are thrown after mixed components had previously been detected and a decision was made to allow them to coexist. The exceptions indicate that a component name collision (resource name or class package name) was detected between trusted and untrusted components and the request to load the resource or class was denied.

Now the problem is, how could i find which classes (maybe org.apache.log4j.Logger?) have the collision and which packages they are in?

I find there is a similar question in Oracle forums

Sathyajith Bhat
  • 21,321
  • 22
  • 95
  • 134
Joey Sun
  • 109
  • 3
  • 8
  • Where is that exception thrown from. I don't see that text in the JDK. Looks similar to the problem of attempting to have to classes in the same package with different certificates, which hasn't been allowed for over ten years. It's possible that you have duplicate class files and they get loaded in a different order. – Tom Hawtin - tackline Jan 13 '11 at 14:38
  • (Oh, and the mixed-code thing only applies to PlugIn/WebStart.) – Tom Hawtin - tackline Jan 13 '11 at 14:58
  • hi Tom, thanks for your info, yes, it is a webstart application, and the J2EE server is JBoss, and our application is only part of the whole product. And I see other applications also use the log4j with different jar files. and i tried to replace our application's log4j jar file with their ones, still the same error. i need to check whether there are other classes which are duplicate. can you give some hint how to find them? since there are a lot of jars, and i just invovled in this product for a few days. thanks. – Joey Sun Jan 14 '11 at 01:13
  • (I was a bit wrong - that text does appear in the deployment code. grepping the wrong directory.) `jar tf` will list files within a jar. You know the package name, so can grep for that. – Tom Hawtin - tackline Jan 14 '11 at 03:43
  • thank you, Tom. i find the collision class name using the jar tf command! – Joey Sun Jan 15 '11 at 14:05

1 Answers1

2

Interesting link. I didn't have the problem yet - but may it be that you have the jar with "org.apache..." in the JavaEE container classpath somewhere and in the web application.

Look for that and to test remove it from the web app

mtraut
  • 4,720
  • 3
  • 24
  • 33
  • 3
    Finally, the problem is solved. and the reason is the jar files listed in the extension JNLP file are signed, but there is no security option in the extension JNLP file, so all the jar files are loaded in the "sandbox", while the other same class in other jar files are loaded as "trusted"， so the mismatch happened. and this issue disappeared when i added the security in the extension JNLP file, the world becomes beau again. hehe. thank you for helping me debugging! – Joey Sun Jan 15 '11 at 14:07
  • @user574287, consider editing the solution into your question. – Thorbjørn Ravn Andersen Jan 27 '11 at 11:47
  • @JoeySun, please explain how to "add the security in the extension JNLP file" – Ivan Gerasimenko Nov 19 '15 at 07:40