My immediate problem is that I don't have an adequate characterization of my problem.
If I run a test in a plain old java object with no explicit Xerces in the classpath at all, it works fine. If I then add all the jars from the webapp's lib to the classpath, it still succeeds. The webapp lib includes xerces 2.9.1 along with a host of others (including xmlapis 1.3.x). If I run the code in tomcat, it fails. If I run the code in jetty, it fails. So, I'm afraid that I've got two issues here. The original issue is whatever causes the validation failure, and then I've run into problems forcing Xerces to be active. Until I can repro the validation error in controlled conditions, I'm in a sorry state. On Thu, Oct 29, 2009 at 2:27 PM, Michael Glavassevich <mrgla...@ca.ibm.com>wrote: > And for those who search the archives, when I say that this has been fixed > for years, I meant it was fixed immediately after the donation of the code. > All of the JAXP 1.3 xml-apis jars which have come from xml-commons have been > released with the correct behaviour, so there are no copies of the Apache > version floating around which have this problem. > > > Michael Glavassevich > XML Parser Development > IBM Toronto Lab > E-mail: mrgla...@ca.ibm.com > E-mail: mrgla...@apache.org > > Michael Glavassevich/Toronto/i...@ibmca wrote on 10/29/2009 02:15:40 PM: > > > > 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. >
