Interesting (?) classloader problem

[Jon Skeet <jo...@peramon.com>]

As observant readers will have noticed, I'm migrating a webapp or two from Tomcat 3.2.3 to Tomcat 4.1. Now, our apps have a very specific version of Xerces that they currently need to use (although I'm hoping this requirement will go away). I believe the version is "Xerces-J 1.4.4" (at least according to the SourceSafe history). Now, that sounds considerably out of whack with what Tomcat ships with, and my guess is that Tomcat may well not be able to work properly with the version we need. (I would just try it, but there's always a good chance that there'll be something hiding away which doesn't get tested.)

I can stick the version of xerces.jar in my webapp's lib directory, but according to the documentation, everything in org.apache.xerces (and the org.xml.sax and org.w3c.dom) packages gets delegated to the parent classloader, which obviously wouldn't help me as I'd pick up the newer version of Xerces instead of the one I need.

There's also another wrinkle which means I need to load xerces.jar *before* any of the other jar files in webapps/lib. I can't remember where exactly this requirement comes from, but I suspect it's due to some other library we use having its own version of xerces (or maybe just the XML API) built in.

I can clearly modify the WebappClassLoader source to get rid of the delegation for org.apache.xerces: what would be the downside of this? Why does the documentation even say you can override common/lib/xerces.jar by putting xerces.jar into webapps/lib, when it's going to delegate everything anyway?

The business about loading xerces.jar first is slightly thorny - I suspect the best solution may be to just find out which other jar file contains the other/wrong classes and take them out, but I'd be interested to hear any other solutions.

Jon