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]
