DO NOT REPLY [Bug 16675] New: - Requst for more convenient classloading with Java 2

[bu...@apache.org]

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=16675>.
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=16675

Requst for more convenient classloading with Java 2

           Summary: Requst for more convenient classloading with Java 2
           Product: XalanJ2
           Version: CurrentCVS
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Xalan
        AssignedTo: xalan-dev@xml.apache.org
        ReportedBy: igor@widespace.ee


This is equivalent of a bug #16674 but for Xalan instead of Xerces.

This is the original text for the bug:

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 Xalan ClassLoader first, but with Java 2
context ClassLoader is consulted first (which is system ClassLoader by default,
i.e ancestor of Xalan ClassLoader).

My proposal is to do additional check as bellow:

------------------------------------------------------
cl = Thread.currentThread().getContextClassLoader();
if (cl == ClassLoader.getSystemClassLoader()) {
  // SecuritySupport12 is from Xerces generalized ClassLoading
  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.

PS. Since Xalan doesn't have generalized ClassLoading I am able to provide
patches for this bug together with generalized ClassLoading as soon as bug issue
become resolved in Xerces. Please tell your thouhts about it. I'm very
interested in more convenient ClassLoading in Xerces and Xalan!