Re: JAXP (in)compatability between Xerces and Crimson
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]
Re: JAXP (in)compatability between Xerces and Crimson
Andy Carlson wrote: Shane, Thanks for your reply. Looks like there may be hope on the horizon! BTW, not everyone agrees that having a separate xml-apis.jar file is the best way to go. I initially thought it was a good idea, but have since changed my mind. You can read some postings on this issue in the archives of [EMAIL PROTECTED] My current opinion is that both the API classes and the implementation classes should be packaged into a single jar, just like xerces.jar works now and the current 1.1.3 version of crimson.jar. However, if there are people who want to release an xml-apis.jar file, even though I don't think that is the best solution, I won't try to stop them either. BTW, even though I don't want to use xml-apis.jar, I still support xml-commons to keep the latest version of the JAXP javax API classes and SAX and DOM interface classes. WRT your JBoss problem, I'd suggest asking on a JBoss list. -Edwin - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAXP (in)compatability between Xerces and Crimson
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) this is quite a well known problem. it boils down to classloaders. standalone tomcat 4.0 works because it has classloaders specially rewritten to work with JAXP. jboss uses a different system of classloaders and requires special configuration to make JAXP work. the bad news is that some ejb containers are even worse than jboss... snip 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. ... 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. - 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. this isn't an apache problem - it's a JAXP problem. even with only one apache implementation you'd still get version conflicts :( if you want deployment independence i'd say you've got two choices: 1. throw away JAXP and directly use the parser of your choice. parser independence is vital for components but isn't really necessary if you're writing a web application. 2. don't deploy any parser libraries with your application and insist that JAXP is correctly set up on the deployment system before you deploy. - robert - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAXP (in)compatability between Xerces and Crimson
robert burrell donkin wrote: this is quite a well known problem. it boils down to classloaders. standalone tomcat 4.0 works because it has classloaders specially rewritten to work with JAXP. jboss uses a different system of classloaders and requires special configuration to make JAXP work. the bad news is that some ejb containers are even worse than jboss... [snip] this isn't an apache problem - it's a JAXP problem. even with only one apache implementation you'd still get version conflicts :( Could you explain what you mean by it's a JAXP problem? From your description, it sounds like the problem is in the container, as Tomcat 4 works as expected. -Edwin - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
