There is a typo in the documentation - you can not override the Xerces parser used. You can replace the one in /common/endorsed and see if it works - I don't recall which version tomcat requires. Have you tried your app with the version that tomcat supplies?
you can't guarantee the order in which jars are loaded within the same classloader, but if you can replace the version in /common/endorsed, then it won't matter what xml classes any web-inf jars include. If you modify the WebappClassLoader class, you will have to maintain it for each tomcat upgrade. You will still need to make sure you get the xerces jar, and not the xml classes from other jars. Charlie > -----Original Message----- > From: Jon Skeet [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 03, 2003 3:58 AM > To: Tomcat User List (E-mail) > Subject: Interesting (?) classloader problem > > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
