> "Remy Maucherat" <[EMAIL PROTECTED]> writes: > > <snip/> > > > > 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. > > I tried removing xerces.jar from common/lib... Didn't see how that would be a > problem since it is Xalan that is trying to instantiate my extensions. Still > didn't work :( > > Putting Xalan in common/lib causes other problems. All my extensions are under > WEB-INF/classes. If I put Xalan under common/lib it is in a new classloader > and I will get Exceptions when it can't find my code. > > I can't move my code from WEB-INF/classes because I am using Tomcat class > reloading to test out new extension code when I am developing... > > Puts us in a tough situation huh ;)
With JDK 1.4, it gets really tricky then, since no matter what the webapp CL has to delegate loading Xalan to the sys CL (ok, it didn't in 4.0.1, but that was a bug). The only way out would be for Xalan to use the context classloader to load its extensions. Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
