Keep in mind that I'm running tomcat and jetty with their respective Maven :run goals. I have to go figure out how one messes with their system classpaths.
On Thu, Oct 29, 2009 at 3:29 PM, Craig Tataryn <crai...@tataryn.net> wrote: > Sounds eriely like a problem I was having deploying my CXF app to WAS > 6.1...[1]. My app was compiling against versions of jaxp which differ from > that which the container/jvm provide. > > Craig > > [1] <http://www.nabble.com/CXF-and-WAS-6.1%28.0.19%29-to26028639.html> > http://www.nabble.com/CXF-and-WAS-6.1%28.0.19%29-to26028639.html > > > On 2009-10-29, at 2:02 PM, Michael Glavassevich <mrgla...@ca.ibm.com> > wrote: > > Thought you weren't sure if you could control the classpath. Was giving you > an option which I would expect to work with vanilla Java 6. Personally I'd > always override with the Apache version given user's experience with what's > included in the JDK. > > FYI: xml-apis 1.4 hasn't been released yet, though will be in time for > Xerces-J 2.10.0. > > Michael Glavassevich > XML Parser Development > IBM Toronto Lab > E-mail: <mrgla...@ca.ibm.com>mrgla...@ca.ibm.com > E-mail: <mrgla...@apache.org>mrgla...@apache.org > > Benson Margulies <bimargul...@gmail.com> wrote on 10/29/2009 02:48:48 PM: > > > Would that require xml-apis-1.4.x? > > > On Thu, Oct 29, 2009 at 2:41 PM, Michael Glavassevich <<mrgla...@ca.ibm.com> > mrgla...@ca.ibm.com > > > wrote: > > If you're using Java 6 (which contains JAXP 1.4) you could try > > DocumentFactory.newInstance(String factoryClassName, ClassLoader > > loader) and its counterparts in the other JAXP factories. Gives you > > full control over what gets loaded and is slightly better than > > directly instantiating the implementation classes yourself. > > > > > > Michael Glavassevich > > XML Parser Development > > IBM Toronto Lab > > E-mail: <mrgla...@ca.ibm.com>mrgla...@ca.ibm.com > > E-mail: <mrgla...@apache.org>mrgla...@apache.org > > > Benson Margulies <bimargul...@gmail.com> wrote on 10/29/2009 02:29:04 > PM: > > > > > > > Michael, > > > > > > I'm not sure that I can grab control of the whole classpath. Is > > > there a way to use more Xerces explicit APIs than just the > > > DocumentBuilderFactoryImpl and XMLSchemaFactory and get an entirely > > > Xerces environment? > > > > > > --benson > > > > > > > > On Thu, Oct 29, 2009 at 2:15 PM, Michael Glavassevich > > > <<mrgla...@ca.ibm.com> > mrgla...@ca.ibm.com > > > > wrote: > > > I've seen that many times before. > > > > > > There's a well known bug [1][2] (at least well known to me) in the > > > base class of SchemaFactory and XPathFactory in the JDK which causes > > > the default implementation to be picked up rather than the one that > > > should have been found through META-INF/services. The Apache version > > > of these classes (which were donated from Sun Java 5) has had a fix > > > for years. I bet if you put the Apache version of xml-apis.jar in > > > the endorsed directory (or at the front of the bootclasspath) this > > > problem goes away. > > > > > > Thanks. > > > > > > [1] <http://markmail.org/message/rvlroblxyza3xt3v> > http://markmail.org/message/rvlroblxyza3xt3v > > > [2] <http://markmail.org/message/bntj64gxademl5ex> > http://markmail.org/message/bntj64gxademl5ex > > > > > > > > > Michael Glavassevich > > > XML Parser Development > > > IBM Toronto Lab > > > E-mail: <mrgla...@ca.ibm.com>mrgla...@ca.ibm.com > > > E-mail: <mrgla...@apache.org>mrgla...@apache.org > > > > > Benson Margulies <bimargul...@gmail.com> wrote on 10/29/2009 02:00:22 > PM: > > > > > > > > > > By the way, is this combination of parsers in a backtrace alarming? > > > > > > > > at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper. > > > > createSAXParseException(ErrorHandlerWrapper.java:195) > > > > at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper. > > > > error(ErrorHandlerWrapper.java:131) > > > > at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter. > > > > reportError(XMLErrorReporter.java:384) > > > > at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter. > > > > reportError(XMLErrorReporter.java:318) > > > > at com.sun.org.apache.xerces.internal.impl.xs. > > > > XMLSchemaValidator$XSIErrorReporter. > > reportError(XMLSchemaValidator.java:410) > > > > at com.sun.org.apache.xerces.internal.impl.xs. > > > > XMLSchemaValidator.reportSchemaError(XMLSchemaValidator.java:3165) > > > > at com.sun.org.apache.xerces.internal.impl.xs. > > > > XMLSchemaValidator.processAttributes(XMLSchemaValidator.java:2630) > > > > at com.sun.org.apache.xerces.internal.impl.xs. > > > > XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:2037) > > > > at com.sun.org.apache.xerces.internal.impl.xs. > > > > XMLSchemaValidator.startElement(XMLSchemaValidator.java:685) > > > > at com.sun.org.apache.xerces.internal.jaxp.validation. > > > > ValidatorHandlerImpl.startElement(ValidatorHandlerImpl.java:549) > > > > at org.apache.xerces.jaxp.JAXPValidatorComponent$XNI2SAX. > > > > startElement(Unknown Source) > > > > at org.apache.xerces.jaxp.JAXPValidatorComponent. > > > > startElement(Unknown Source) > > > > at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl. > > > > scanStartElement(Unknown Source) > > > > at org.apache.xerces.impl. > > > > XMLDocumentFragmentScannerImpl$FragmentContentDispatcher. > > > > dispatch(Unknown Source) > > > > at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl. > > > > scanDocument(Unknown Source) > > > > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown > Source) > > > > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown > Source) > > > > at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) > > > > at org.apache.xerces.parsers.DOMParser.parse(Unknown Source) > > > > at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown > Source) > > > > at > javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:124) > > > > > > > > > > > On Thu, Oct 29, 2009 at 1:41 PM, Michael Glavassevich > > > > <<mrgla...@ca.ibm.com> > mrgla...@ca.ibm.com > > > > > wrote: > > > > Hi Benson, > > > > > > > > DocumentBuilderFactory and the other JAXP factories use the current > > > > thread's context ClassLoader by default for locating the > > > > implementation. If for whatever reason the implementation you wanted > > > > loaded isn't visible to this ClassLoader you'll get a different > > > > implementation, most likely the default one in the JDK. Couldn't > > > > tell you how this is occurring in your environment. I've never used > > > > Tomcat or Maven. > > > > > > > > Thanks. > > > > > > > > Michael Glavassevich > > > > XML Parser Development > > > > IBM Toronto Lab > > > > E-mail: <mrgla...@ca.ibm.com>mrgla...@ca.ibm.com > > > > E-mail: <mrgla...@apache.org>mrgla...@apache.org > > > > > > > > Benson Margulies <bimargul...@gmail.com> wrote on 10/29/2009 > 12:35:42 PM: > > > > > > > > > > > > > I have some code that uses DocumentBuilderFactory etc. (JAXP) to > > > > > parse a document with W3C schema validation. > > > > > > > > > > My unit tests work fine with Xerces in the classpath. > > > > > > > > > > When the business is all packaged into a webapp and deployed in > > > > > tomcat (via mvn tomcat:run), the validation fails with bogus error, > > > > > > and the backtrace shows that I'm using whatever nasty version of > > > > > JAXP is sitting in the JVM. Short of calling > > > > > DocumentBuilderFactoryImpl, can anyone tell me what I'm doing > wrong? > > > > > The xerces Jar is in the WAR file in the right place. > >
