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" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
