On 09/03/2003 05:54 AM Craig R. McClanahan wrote:
On Wed, 3 Sep 2003, Andrew Hill wrote:
Date: Wed, 3 Sep 2003 11:21:55 +0800 From: Andrew Hill <[EMAIL PROTECTED]> To: Struts Users Mailing List <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: [OT] XML Parsers vs WEB-INF/lib [WAS: RE: Commons Versions bundled with Struts 1.1]
So whats the deal with XML parsers?
For example lets say I need my web app to use xerces-1.4.3 as later versions have various bugs with some of the things Im trying to do (for example xerces-1.4.4's Document.cloneNode() is screwed, and 2.something's EntityResolver gets fed incorrect info, etc... (and the other parsers like crimson are even worse and slow too!))
Rather than hope with crossed fingers that my app will play nice with whatever unknown and untested parser the customer has in their appserver (& if it doesnt we all know who gets blamed) I'd like to be able to include the xerces jar in WEB-INF/lib and have it used instead of the shared one - yet this isn't what happens.
What gives?
<disclaimer> I am doing this from memory, and haven't personally reverified everything, but I *think* this is how it all works. </disclaimer>
Short answer -- you're in the Java version of "DLL Hell".
Long answer -- it depends on both your servlet container and your JDK version. Let's take the latter situation first, because this consideration overrides.
* JDK 1.4 or later -- because a JAXP compatible parser is built in, you cannot simply replace it by including a parser, either inside the webapp or in Tomcat's common/lib directory. Instead, you have to convince the JDK to use your parser instead of the built-in one. There are two general approaches:
- Use the "discovery mechanism" described in the JAXP Specification to tell the JDK what DocumentBuilder or SAXParser implementation class should be used. See the JAXP Spec for more info. This won't work if you simply want to use a different version of the same parser that is built in to the JDK (i.e. Sun JDK uses Xerces).
- Put your replacement parser into the "JDK Extensions" directory, either $JAVA_HOME/jre/lib/ext or whatever directory you define on the command line with the "java.endorsed.dirs" system property. This is how Tomcat 4.1, 5.0, and the Java Web Services Developer Pack 1.2 deal with this situation -- the parser they want to use goes in the "$CATALINA_HOME/common/endorsed" directory.
* JDK 1.3 or earlier -- you can replace the server's parser by including it in your webapp, IF AND ONLY IF your server implements the *optional* capability in the Servlet Spec to allow webapp libraries to override server supplied libraries. Check the docs for your server to see if it does this (Tomcat 4.1 and 5.0 do, last time I checked).
Craig
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- struts 1.1 + tomcat 4.1.27 + java 1.4.2 Linux 2.4.20 RH9
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]