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 [2] http://markmail.org/message/bntj64gxademl5ex Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrgla...@ca.ibm.com E-mail: 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 > > 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 > E-mail: 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.>