DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16674>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16674

Requst for more convenient classloading with Java 2

           Summary: Requst for more convenient classloading with Java 2
           Product: Xerces2-J
           Version: 2.3.0
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Other
        AssignedTo: [EMAIL PROTECTED]
        ReportedBy: [EMAIL PROTECTED]


Currently in multi-classloader environment (like Eclipse plugins or
web-applications) there is a need to use
Thread.currentThread().setContextClassLoader(cl); even in cases where this could
be avoided. This happens only with Java 2 environment because in 1.1 JVMs you
always try to load classes from Xerces ClassLoader first, but with Java 2
context ClassLoader is consulted first (which is system ClassLoader by default,
i.e ancestor of Xerces ClassLoader).

My proposal is to do additional check as bellow:

------------------------------------------------------
cl = Thread.currentThread().getContextClassLoader();
if (cl == ClassLoader.getSystemClassLoader()) {
  cl = SecuritySupport12.class.getClassLoader();
}
------------------------------------------------------

It should completely safe to do this since the only working case is when Xerces
ClassLoader or it's descendant are used:
1) if Xerces in system ClassLoader, then it is the same ClassLoader
2) if Xerves in any custom ClassLoader then lookup in system ClassLoader will
eicher:
2.a) find nothing (and then fallback to Xerces ClassLoader)
2.b) find wrong class and get ClassCastException later

A bit more about [2.b]:
Some JVM's soed include Xerces in distribution. There is a need for a program to
use newer version of Xerces. Endorsed mechanizm is not always acceptable,
especially if it is a requirement to work with unmodified JVMs...
It isn't hard to hide sytem version of Xerces in own custom ClassLoader, but
then you get this issue.

If Xerces developers have something against this please start discussing. I'd
like to resolve this issue ASAP.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to