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 E-mail: 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 > > 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 > [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.
