try putting the Xerces 2.9.1 jars in $TOMCAT_HOME/common/lib or
.../endorsed (depends on version of Tomcat).
Jeff
Benson Margulies wrote:
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 <mailto: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 <mailto:mrgla...@ca.ibm.com>
E-mail: mrgla...@apache.org <mailto: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 <mailto:mrgla...@ca.ibm.com>
> E-mail: mrgla...@apache.org <mailto:mrgla...@apache.org>
>
> Benson Margulies <bimargul...@gmail.com
<mailto: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 <mailto: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 <mailto:mrgla...@ca.ibm.com>
> > E-mail: mrgla...@apache.org <mailto:mrgla...@apache.org>
> >
> > Benson Margulies <bimargul...@gmail.com
<mailto: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.
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org
For additional commands, e-mail: j-users-h...@xerces.apache.org
