Shane, Thanks for your reply. Looks like there may be hope on the horizon!
And to think that when I started composing the mail I thought it was going to be a bug report which could get fixed quickly. I later realised that I couldnt really either a) find a specific bug or b) blame any single component, just the whole process. Oh well... I suppose we would be out of a job if everything worked like you wanted it to. Cheers, Andy ---------------------------------------------------------------- Andy Carlson >From: [EMAIL PROTECTED] >Reply-To: [EMAIL PROTECTED] >To: [EMAIL PROTECTED] >Subject: Re: JAXP (in)compatability between Xerces and Crimson >Date: Fri, 9 Nov 2001 11:50:27 -0500 > >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] > _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp --------------------------------------------------------------------- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
