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