RE: Interesting (?) classloader problem
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]
RE: Interesting (?) classloader problem
There is a typo in the documentation - you can not override the Xerces parser used. Aha. That at least explains my confusion :) 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? I haven't yet, to be honest - hopefully I'll be able to use that in the end, but the guy whose code is most likely to use internal xerces/xalan interfaces is on holiday this week... 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. Fortunately, I've found that isn't a problem any more. I'm not sure when it was, but it seems to be okay now. I checked which classes were duplicated, and they only seem to be the standard interfaces/base classes, not the implementations. I wish I could find the bug report for what was wrong before... If you modify the WebappClassLoader class, you will have to maintain it for each tomcat upgrade. Indeed. We very rarely upgrade though, to be honest, so that shouldn't be a problem - and hopefully I'll be able to get rid of it soon and we can use the standard xerces when my colleague comes back. I just wanted something to get up and running to start with. Jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Interesting (?) classloader problem
Howdy, I saw from the other messages you already have a workaround, but here's another suggestion anyways: take the xerces that comes with tomcat and put it in $CATALINA_HOME/server/lib. Take the one your app needs and put it in the endorsed directory. See what happens ;) But as you yourself said, the better course is to upgrade to the 2.x branch of xerces, which is now stable, mature, fast, robust, etc etc etc. Yoav Shapira Millennium ChemInformatics -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] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
