[
http://jira.jboss.com/jira/browse/JBAS-4536?page=comments#action_12368516 ]
Adrian Brock commented on JBAS-4536:
------------------------------------
This has been fixed by ignoring java.* classes in deployments.
The java.* packages are still searched for resources.
This is not ideal since we end up throwing ClassNotFoundException instead of
SecurityException,
but it is better to get a "ClassNotFoundException: java.not.allowed" than an
even more confusing
"ClassNotFoundException: java.util.Set" when somebody includes the latter class
in their deployment.
With the current JMX Classloaders there's no way to tell the difference between the
two situations
since there is no explicit policy on what should be always delegated to the parent like
java.*
(or an easy place to introduce such a notion).
Isolated classloading is incorrectly isolating java.* classes
-------------------------------------------------------------
Key: JBAS-4536
URL:
http://jira.jboss.com/jira/browse/JBAS-4536
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: ClassLoading
Affects Versions: JBossAS-4.2.1.GA
Reporter: Adrian Brock
Assigned To: Adrian Brock
Fix For: JBossAS-5.0.0.Beta3, JBossAS-4.2.2.GA
If you isolate your classloading and then include a class in the jar that is a java.*
class from the JDK
it never delegates the request to the JDK. Instead you get a ClassNotFoundException
because you are only allowed to load java.* classes from outside the bootstrap
classloader.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira