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

WebappClassLoader delegates to parent loader

[EMAIL PROTECTED] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |



------- Additional Comments From [EMAIL PROTECTED]  2003-01-30 18:34 -------
Remy,

Even if this behavior is not *required* by the specification it is still a
good idea to be backward compatible with previous Tomcat releases (IMHO).

The reason why this matters to us (the company I work for), is that some of
our code is designed to work with particular versions/implementations of
libraries.

I think I see how this can be fixed:
Note the private field defined on line 192 of the source...

    /**
     * Set of package names which are not allowed to be loaded from a webapp
     * class loader without delegating first.
     */
    private static final String[] packageTriggers = {
        "javax",                                     // Java extensions
        "org.xml.sax",                               // SAX 1 & 2
        "org.w3c.dom",                               // DOM 1 & 2
        "org.apache.xerces",                         // Xerces 1 & 2
        "org.apache.xalan"                           // Xalan
    };


The loading classes from packages starting with the above names is
delegated to the parent loader.  This behavior is not backward compatible
with previous class loading behavior.  In particular, this makes the use
of another XML library not possible within a given app context. (Yes, there
are other problems when running against the 1.4 version of the JDK with the
XML libraries, but that is another matter.)

I'm not sure why it is here in the first place, but the simple solution
is to empty this private string array field.

Regards,
-Babak

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

Reply via email to