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

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

Reply via email to