xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shane_Curc...@lotus.com
Subject Re: JAXP (in)compatability between Xerces and Crimson
Date Fri, 09 Nov 2001 16:50:27 GMT
One ray of (potential) hope is the first product from the xml-commons
subproject: xml-apis.jar.  We haven't yet had an official release yet,
although I just might do one soon to match Xalan's planned 2.2D12 release
in the next day or so.

The point of xml-apis.jar is to hold externally-defined standards based XML
related files, to use a few too many adjectives.  This essentially means
our own copies of DOM L2, SAX 2.x and JAXP 1.1.x.  If we can get a number
of other subprojects to cooperate, we can all get these common and usually
backwards-compatible standards files from the same place: xml-apis.jar.
We're hoping that will be a reasonable solution to the mismatched JAXP
problems.

---- you  "Andy Carlson" <andyslistbox@hotmail.com> wrote ----
> Hi all, I've just spent quite a while tracking down a weird problem...
I'm running a servlet under Tomcat 4.0. The servlet includes Axis, which in
> this case is using the Xerces (1.4.3) parser. Everything works fine - no
> problem so far... Now I try to run the same servlet on Tomcat 4.0
embedded in JBoss (2.4.1)
> and I get the following:
> - java.lang.ClassCastException:
> org.apache.crimson.jaxp.DocumentBuilderFactoryImpl
> at
javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:152)



> So what's the answer?
> - at the moment the answer seems to be to avoid mixing Crimson and Xerces
in
> the same context unless you have a very good understanding of how they
are
> going to interact with each other - you might get away with it or you
might
> (like me) spend a long time chasing strange problems.
Yup, especially since JAXP has undergone some changes in exactly how it
looks up factories recently that make the code behave differently and have
different classes (under the covers).  But there are a lot of other
situations (depends on servlet container and some specific parser versions)
where I've had multiple parsers play happily.

> ... but this is bad news because it means that if my servlet uses an XML
> parser, I have to check whether the app server I'm deploying on is using
> another one in a way which is going to cause a conflict.
Ah - part of the solution is JAXP, which means at least you shouldn't have
to change your code - just perhaps change part of the environment without
recompiling etc.  So, part of this issue also lies with various servlet
containers, which each may have hidden quirks with classloaders etc.

> - For the future it would seem to be a better approach to agree on a
single
> implementation of JAXP within Apache, put it in its own JAR and
explicitly
> disallow (in the JAXP spec?) XML parser implementations from
reimplementing
> all or part of JAXP in their own JARs.
Interesting point; but there's a fine line between defining a high-level
spec like JAXP and specifying too many implementation details without solid
enough history behind them.  In the end, the real decision is with Sun,
since they own the core JAXP spec; Apache will just continue providing some
useful implementations thereof...

- Shane


---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org


Mime
View raw message