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: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 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!
