Marco, I'm a little at a loss to tell you what to do. I don't know the "parser.jar". Is it homemade or is it some older third party offering?
My next questions would be: Is parser.jar completely superceded by xerces? If so then throw it away. If not then is it a mixture of a incompatible parser and required behaviour? (If not, then what the heck is it for?) Will this behaviour run with Xerces? If so then you can repackage it or you can fiddle with the class paths. (I prefer not to rely on classpaths for loading because it's an implicit dependency that tends to get forgotten and cause problems the next time someone changes the classpath). You then just replace the parser.jar with the "everythingbutparser.jar" where needed. If it won't work with Xerces then you have two incompatible jars and you'll have some programming to do to fix them. _________________________________________ Neil Pitman [EMAIL PROTECTED] +1.514.863.5465 ICQ#: 21101052 _________________________________________ ----- Original Message ----- From: "Giana Marco" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, September 01, 2003 3:28 AM Subject: AW: AW: xmlParserAPIs.jar and parser.jar Neil, that is fine, but some machines will have parser.jar and some will not. Am I building a mountain out of a mole hill? Should I just suggest that if parser.jar exists, then delete it as xmlParserAPIs.jar contains all the classes/implementations ? Regards Marco Giana -----Urspr�ngliche Nachricht----- Von: Neil Pitman [mailto:[EMAIL PROTECTED] Gesendet: 29 August 2003 23:05 An: [EMAIL PROTECTED] Betreff: Re: AW: xmlParserAPIs.jar and parser.jar Marco, Why don't you repackage it. Extract eveything, delete all the JAXP stuff and JAR it. _________________________________________ Neil Pitman [EMAIL PROTECTED] +1.514.863.5465 ICQ#: 21101052 _________________________________________ ----- Original Message ----- From: "Giana Marco" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, August 29, 2003 3:36 AM Subject: AW: AW: xmlParserAPIs.jar and parser.jar Hi Jake, I figured that this would be the case, but is there not way to get around this without deleting it ? Regards Marco -----Urspr�ngliche Nachricht----- Von: Jacob Kjome [mailto:[EMAIL PROTECTED] Gesendet: 28 August 2003 18:56 An: [EMAIL PROTECTED] Betreff: Re: AW: xmlParserAPIs.jar and parser.jar parser.jar, obviously, contains old versions of the endorse packages such as org.w3c.dom.*, org.xml.*, javax.xml.*, etc... xmlParserAPIs.jar (or, again, xml-apis.jar) contain the latest versions of these libraries. Forget parser.jar. Delete it and just use the new stuff. Jake At 05:38 PM 8/28/2003 +0200, you wrote: >Hi Jake, > >parser.jar is just another JAR file for xml parsing, which was located on >our machine. >It has nothing to do with Xerces. But it is used by other applications >requiring >XML parsing. For me to use Xerces, I added the necessary jar files, which >includes >xmlParserAPIs.jar. These two jar files contains both >org.w3c.dom.DOMImplementation, >which is why I am getting the problem. > >I was wondering how to fix my "cannot resolve symbol", without deleting >parser.jar. > >Cheers > >Marco > >-----Urspr�ngliche Nachricht----- >Von: Jacob Kjome [mailto:[EMAIL PROTECTED] >Gesendet: 28 August 2003 16:50 >An: [EMAIL PROTECTED] >Betreff: Re: xmlParserAPIs.jar and parser.jar > > > >What's "parser.jar"? You should have xmlParserAPIs.jar (or xml-apis.jar) >and xercesImpl.jar. > >Jake > >At 10:17 AM 8/28/2003 +0200, you wrote: > >Hi all, > > > >this is more a general Java question, but it is associated with Xerces. > > > >I am currently writing library of classes to obviously process some XML > >documents, using jdk1.3.1_01. > > > >I have places the necessary jar files in jdk1.3.1_01\jre\lib\ext to be able > >to compile and run. > >The machines which will use this also contain parser.jar in this directory. > >When I go to compile the classes I get the following error, > > > >mapbroker/MBXML.java:97: cannot resolve symbol > >symbol : method createDocument (java.lang.String,java.lang.String,<null>) > >location: interface org.w3c.dom.DOMImplementation > > Document subDocument = domImpl.createDocument("", "roottagname", > >null); > > > >Now when I remove parser.jar, everything compiles and runs without a > >problem. > >This leads me to believe that cause both jar files contain the > >org.w3c.dom.DOMImplementation, then the JVM cannot resolve which one to >use. > >Now I thought depending on which order these are loaded in the classpath, > >then it will use the first. It seems to me placing the jars in \jre\lib\ext > >does not do this. Well it is more of a case that I do not really understand > >what happens to these files when java application starts. > > > >So my question is how can I have both of these files in \jre\lib\ext and > >have java resolve it. > > > >Also this will be run as both for a stand alone application, which is where > >I have encountered this problem, and as a web application. > >using ServletExec. I have not done any test for the web application, but I > >suppose I could add the xmlParserAPIs.jar > >to the Java Virtual Machine (VM) Classpath, which should resolve this > >problem for my web application. > >Regards > >Marco Giana > > > > > > > >___________________________________________________________ > >Marco Giana > >mailto:[EMAIL PROTECTED] > >WebGIS-Entwicklung Phone:++43 1 87806 > >ext. 49 > >SynerGIS Informationssysteme GmbH Fax:++43 1 87806 ext. >98 > >Amalienstrasse 65 > >A-1130 Wien > >http://www.synergis.co.at > >___________________________________________________________ > > > >18. European ESRI User Conference Oct 8-10, Innsbruck > >10. Deutschsprachige ESRI Anwenderkonferenz 8.-10.10. Innsbruck > >GIS @ Work http://www.esri2003.info > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
