> "Remy Maucherat" <[EMAIL PROTECTED]> writes: > > > > "Remy Maucherat" <[EMAIL PROTECTED]> writes: > <snip/> > > > > This is the wierdness that I was talking about. What Xalan bug did you fix? > > > > The javax.xml packages couldn't be loaded from the webapp repository (because > > of the way delegation works in the servlet API, the base XML classes can't be > > loaded from the webapp without causing lots of trouble; however, that > > resptriction was too broad, adn is now restricted to the base SAX and DOM > > classes, as well as the core JAXP XML parser interfaces). > > This is what I assumed the problem is... I have spent a lot of time debugging > Tomcat classloader issue (though certainly not as much as other people here). > > My document on Tomcat classloading that I am referencing: > > http://jakarta.apache.org/tomcat/tomcat-4.0-doc/class-loader-howto.html > > ... but it looks like things have changed below... > > > > Could you give me more insight here? > > > > If Xalan needs a newer version of the SAX, DOM, or JAXP XML parser APIs than > > what is in common/lib to support extensions, you'll have to replace it > > there. 4.0.1 allowed you to override them (which created some problems in many > > cases), > > OK.. I think that this should be documented in class-loader-howto.html > > > and 4.0.2/4.0.3/4.0.4b1 don't. > > Yes... this is my experience exactly. > > > Also, if JAXP is in the system classloader, you can never override it. > > Ug... > > "As mentioned above, the web application class loader diverges from the default > Java 2 delegation model (in accordance with the recommendations in the Servlet > Specification, version 2.3, section 9.6). When a request to load a class from > the web application's WebappX class loader is processed, this class loader will > look in the local repositories first, instead of delegating before looking. All > other class loaders in Tomcat 4 follow the usual delegation pattern." > > Does this mean that Tomcat is now NOT in complaince with the Servlet 2.3 spec???
No, everything is mostly ok and the docs are relatively up to date. You just forgot to read $9.7.2 in the spec. I think the CL scheme recommended by the servlet API is as close to being unimplementable (at least in a working fashion) as you can get. I'm not losing all hope just yet, though ;-) The thing is that 'J2SE classes' is a moving target ... In 4.0.4 b1, I prevent loading from the webapps anything which can be loaded with the sys CL, which seems reasonable since with Catalina it doesn't contain much more than the J2SE classes. To harmonize between the different J2SE versions, I was considering using tricks (namely, the 'Class-Path' attribute of the JARs) to put JNDI and JAXP/Xerces in the sys classloader, therefore removing the need for the custom class exclusion code in the webapp CL. Unfortunately, I think that would still lead to breaking the Xalan extensions you're using. It's also not terribly robust (if you rename the JAR, or use another implementation, it will break). > > Which JDK are you using ? I assume 1.3.x. > > 1.2.x, 1.3.x, 1.4.x ... need to support them all. > > > I'll do my best to continue improving the CL (so that all the exclusions > > tricks would be unnecessary), but I'm running out of ideas for some cases > > (JAXP, JNDI, the servlet API). I'll try to fix it for 4.0.4 b2. > > Hm... so what are the options? Stop using Tomcat WebApp classloader? Move all > my .jars into common/lib ? IMO, you don't need to move everything, but you could exepriment removing the XML parser and putting Xalan in common/lib, and see if it helps. We're experimenting here. Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
