The Java XML parser situation is pretty bad at the moment. Not only is versioning a nightmare, but the average developer isn't given too much information as to what is flat out obsolete, and what the JARs really do. Here's a nutshell view, although it sounds like you're over the hump and are sorting things out. Also, as much as I try to stay on top of things, I likely have made some errors here, too. (1) xml.jar - old Sun parser, development stopped in 1999, showed up in Tomcat and Ant and elsewhere until recently. Avoid unless necessary. (2) JAXP stuff - jaxp.jar and parser.jar in the original; jaxp.jar and crimson.jar in the latest distributions. Things like Ant will still typically have the old JAXP. jaxp.jar is the API; crimson.jar is an implementation. No real reason to ever use Crimson, but that's just my opinion. By definition, avoid parser.jar. (3) Xerces - xerces.jar, derived from xml4j.jar (now they are one and the same, more or less). This keeps up with all the APIs, and there is no reason not to use it for _all_ parsing. Apache XML has both Xerces and Crimson, but that's more a political thing and again IMO one should stick with Xerces. (4) Xalan - xalan.jar. 2J does TRAX. I'm partial to SAXON myself, but Xalan is pretty good. The reason I mention Xalan is because JAXP covers XSLT also, and XSLT is frequently part of the equation. You won't have to use separate sax.jar and dom.jar libraries anymore unless you're using something ancient like XP, which you ought not to be using anymore anyway. Parsers like Crimson and Xerces include all those classes. Basic recommendations: if the application uses JAXP APIs, then stick with Xerces and Xalan. Can't speak for Orion, but JAXP is in the distribution - it seems to me that it's there for a reason. If they have hardwired references that's unfortunate, because it defeats JAXP, and I hope they fix it. The entire purpose of JAXP is to enable this. Ruthlessly purge all references to xml.jar, parser.jar and crimson.jar - your life will simplify greatly. Plus, always use the Xerces that comes with the Xalan that you are using. Finally, I recommend reading the JAXP spec. You'll see that the key contribution here is interoperability, through the use of the javax.xml.parsers and javax.xml.transform packages; most everything else in the spec is saying that they use SAX, and DOM, and TRAX. Hope this helps some. I'm not suggesting that _you_, in particular, need to know this - it just seemed to me that it's a useful summary at this juncture. Regards, Arved Sandstrom -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Doust Sent: Friday, February 23, 2001 9:56 PM To: Orion-Interest Subject: RE: JAXP Tim, Thanks for trying to help. I'll take a look in the mailing list archives. I looked through the first set and didn't find anything, but I can look at older stuff. In the meantime, I'm replacing the jaxp.jar, parser.jar, and xalan.jar that came with Orion (latest version) with crimson.jar, jaxp.jar and xalan.jar from JAXP 1.1. After a thorough analysis of these jar files, I found that xalan.jar and crimson.jar have most of what jaxp.jar and parser.jar have plus a lot more. One of the problems I have is that ant, jdk1.3, orion, and jaxp1.1 each come with a different version of jaxp.jar. Orion, jdk1.3 and jaxp1.1 each comes with a different version of xalan.jar. Orion and ant come with different versions of parser.jar. (I have all four of these installed.) ant worked okay after replacing its jaxp.jar and parser.jar with jaxp1.1's xalan.jar and crimson.jar. I start Orion with a classpath that includes the crimson.jar and xalan.jar from jaxp 1.1. During the startup, when its trying to parse its config files (I guess) I get a NoSuchMethodError at org.apache.crimson.tree.AttributeSet.<init>(AttributeSet.java:139). I guess I can't tell from this what method it's trying to call. It would be helpful if I could. Somehow, it sounds internal to JAXP, and not like it's really a problem of Orion. Any more ideas now that I've given all these details? Love to hear from you again! Rich -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tim Endres Sent: Friday, February 23, 2001 8:33 PM To: Orion-Interest Subject: Re: JAXP Hi Rich, Could you narrow it down? Specifically which JAR breaks Orion. We have replaced the xalan.jar and xerces.jar files with version 1.2.2 and Orion is happy. Is it just the jaxp.jar file that is the issue? Also, I believe that somewhere in the mailing list archives, you will find posts related to JAXP, but I do not know if they will address your specific question. tim. > I have been working on this problem all day. I have posted once before and > no one responded. I will try again. > I'm no Java expert and this is just my ignorance, but can anyone tell me if > I'm correct in my assumptions on this. > I am trying to develop server side code that runs under Orion that uses the > JAXP code that Sun has recently released. There are different versions of > parser.jar, xalan.jar and jaxp.jar distributed with Orion. Older ones. I > have tried replacing the older ones with the newer ones because my code > requires the newer ones and I guess that my code will be running in the same > image as Orion. Orion fails to start due to an exception while trying to > parse its configuration files. Putting the old .jar files back, it works > again. So, now it occurs to me that I'm basically stuck running with > whatever version of support code the tools I'm using are dependent on. > If I'm right, that means I can't use the latest version of JAXP until Orion > does? Is that right? > Anyone? > Thanks, > Rich > >
