[prev in list] [next in list] [prev in thread] [next in thread]
List: xerces-j-dev
Subject: Re: Webapp classpath confusion
From: Benson Margulies <bimargulies () gmail ! com>
Date: 2009-10-29 20:19:59
Message-ID: 61b5d9410910291319i4cbba3c8o53ee6e227794c936 () mail ! gmail ! com
[Download RAW message or body]
PROBLEM SOLVED if not completely explained.
Step 1: Exclude xml-apis-1.3.x from the dependencies of xerces 2.9.1,
leaving me with just the 1.6 Java API (JAXP 1.4).
Step 2: Use the new API to create both the DocumentBuilderFactory and the
SchemaFactory.
And all is swell.
This is going to make my JBoss customer peeved about their stupid 'endorsed'
business, but so it goes.
I still don't know why the container plugins get into this mess.
On Thu, Oct 29, 2009 at 3:36 PM, Benson Margulies <bimargulies@gmail.com>wrote:
> Keep in mind that I'm running tomcat and jetty with their respective Maven
> :run goals. I have to go figure out how one messes with their system
> classpaths.
>
>
> On Thu, Oct 29, 2009 at 3:29 PM, Craig Tataryn <craiger@tataryn.net>wrote:
>
>> Sounds eriely like a problem I was having deploying my CXF app to WAS
>> 6.1...[1]. My app was compiling against versions of jaxp which differ from
>> that which the container/jvm provide.
>>
>> Craig
>>
>> [1] <http://www.nabble.com/CXF-and-WAS-6.1%28.0.19%29-to26028639.html>
>> http://www.nabble.com/CXF-and-WAS-6.1%28.0.19%29-to26028639.html
>>
>>
>> On 2009-10-29, at 2:02 PM, Michael Glavassevich <mrglavas@ca.ibm.com>
>> wrote:
>>
>> 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: <mrglavas@ca.ibm.com>mrglavas@ca.ibm.com
>> E-mail: <mrglavas@apache.org>mrglavas@apache.org
>>
>> Benson Margulies <bimargulies@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 <<mrglavas@ca.ibm.com>
>> mrglavas@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: <mrglavas@ca.ibm.com>mrglavas@ca.ibm.com
>> > E-mail: <mrglavas@apache.org>mrglavas@apache.org
>>
>> > Benson Margulies <bimargulies@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 <<mrglavas@ca.ibm.com>
>> mrglavas@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>
>> http://markmail.org/message/rvlroblxyza3xt3v
>> > > [2] <http://markmail.org/message/bntj64gxademl5ex>
>> http://markmail.org/message/bntj64gxademl5ex
>> > >
>> > >
>> > > Michael Glavassevich
>> > > XML Parser Development
>> > > IBM Toronto Lab
>> > > E-mail: <mrglavas@ca.ibm.com>mrglavas@ca.ibm.com
>> > > E-mail: <mrglavas@apache.org>mrglavas@apache.org
>> >
>> > > Benson Margulies <bimargulies@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 <<mrglavas@ca.ibm.com>
>> mrglavas@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: <mrglavas@ca.ibm.com>mrglavas@ca.ibm.com
>> > > > E-mail: <mrglavas@apache.org>mrglavas@apache.org
>> > > >
>> > > > Benson Margulies <bimargulies@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.
>>
>>
>
[Attachment #3 (text/html)]
PROBLEM SOLVED if not completely explained.<br><br>Step 1: Exclude xml-apis-1.3.x \
from the dependencies of xerces 2.9.1, leaving me with just the 1.6 Java API (JAXP \
1.4).<br><br>Step 2: Use the new API to create both the DocumentBuilderFactory and \
the SchemaFactory.<br> <br>And all is swell.<br><br>This is going to make my JBoss \
customer peeved about their stupid 'endorsed' business, but so it \
goes.<br><br>I still don't know why the container plugins get into this \
mess.<br><br> <br><div class="gmail_quote">On Thu, Oct 29, 2009 at 3:36 PM, Benson \
Margulies <span dir="ltr"><<a \
href="mailto:bimargulies@gmail.com">bimargulies@gmail.com</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, \
204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Keep in mind that I'm \
running tomcat and jetty with their respective Maven :run goals. I have to go figure \
out how one messes with their system classpaths.<div><div></div><div \
class="h5"><br><br><div class="gmail_quote"> On Thu, Oct 29, 2009 at 3:29 PM, Craig \
Tataryn <span dir="ltr"><<a href="mailto:craiger@tataryn.net" \
target="_blank">craiger@tataryn.net</a>></span> wrote:<br> <blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;"><div bgcolor="#FFFFFF"><div>Sounds eriely like a \
problem I was having deploying my CXF app to WAS 6.1...[1]. My app was compiling \
against versions of jaxp which differ from that which the container/jvm \
provide.</div>
<div><br></div><div>Craig</div><div><br></div><div>[1] <a \
href="http://www.nabble.com/CXF-and-WAS-6.1%28.0.19%29-to26028639.html" \
target="_blank"></a><a \
href="http://www.nabble.com/CXF-and-WAS-6.1%28.0.19%29-to26028639.html" \
target="_blank">http://www.nabble.com/CXF-and-WAS-6.1%28.0.19%29-to26028639.html</a><br>
<br></div><div><div></div><div><div><br>On 2009-10-29, at 2:02 PM, Michael \
Glavassevich <<a href="mailto:mrglavas@ca.ibm.com" \
target="_blank">mrglavas@ca.ibm.com</a>> \
wrote:<br><br></div><div></div><blockquote type="cite">
<div>
<p><tt>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.</tt><br>
<br>
<tt>FYI: xml-apis 1.4 hasn't been released yet, though will be in time for \
Xerces-J 2.10.0.</tt><br> <br>
<tt>Michael Glavassevich<br>
XML Parser Development<br>
IBM Toronto Lab<br>
E-mail: <a href="mailto:mrglavas@ca.ibm.com" target="_blank"></a><a \
href="mailto:mrglavas@ca.ibm.com" target="_blank">mrglavas@ca.ibm.com</a></tt><br> \
<tt>E-mail: <a href="mailto:mrglavas@apache.org" target="_blank"></a><a \
href="mailto:mrglavas@apache.org" target="_blank">mrglavas@apache.org</a></tt><br> \
<br> <tt>Benson Margulies <<a href="mailto:bimargulies@gmail.com" \
target="_blank">bimargulies@gmail.com</a>> wrote on 10/29/2009 02:48:48 PM:<br> \
<br> > Would that require xml-apis-1.4.x? <br>
</tt><br>
<tt>> On Thu, Oct 29, 2009 at 2:41 PM, Michael Glavassevich <<a \
href="mailto:mrglavas@ca.ibm.com" target="_blank"></a><a \
href="mailto:mrglavas@ca.ibm.com" target="_blank">mrglavas@ca.ibm.com</a><br> > \
> wrote:</tt><br> <tt>> If you're using Java 6 (which contains JAXP 1.4) \
you could try <br> > DocumentFactory.newInstance(String factoryClassName, \
ClassLoader <br> > loader) and its counterparts in the other JAXP factories. Gives \
you <br> > full control over what gets loaded and is slightly better than <br>
> directly instantiating the implementation classes yourself.</tt><br>
<tt>> <br>
> <br>
> Michael Glavassevich<br>
> XML Parser Development<br>
> IBM Toronto Lab<br>
> E-mail: <a href="mailto:mrglavas@ca.ibm.com" target="_blank"></a><a \
href="mailto:mrglavas@ca.ibm.com" target="_blank">mrglavas@ca.ibm.com</a><br> > \
E-mail: <a href="mailto:mrglavas@apache.org" target="_blank"></a><a \
href="mailto:mrglavas@apache.org" target="_blank">mrglavas@apache.org</a><br> \
</tt><br> <tt>> Benson Margulies <<a href="mailto:bimargulies@gmail.com" \
target="_blank">bimargulies@gmail.com</a>> wrote on 10/29/2009 02:29:04 \
PM:</tt><br> <tt>> <br>
> <br>
> > Michael,<br>
> > <br>
> > I'm not sure that I can grab control of the whole classpath. Is <br>
> > there a way to use more Xerces explicit APIs than just the <br>
> > DocumentBuilderFactoryImpl and XMLSchemaFactory and get an entirely <br>
> > Xerces environment?<br>
> > <br>
> > --benson<br>
> > </tt><br>
<tt>> <br>
> > On Thu, Oct 29, 2009 at 2:15 PM, Michael Glavassevich <<a \
href="mailto:mrglavas@ca.ibm.com" target="_blank"></a><a \
href="mailto:mrglavas@ca.ibm.com" target="_blank">mrglavas@ca.ibm.com</a><br> > \
> > wrote:<br> > > I've seen that many times before.<br>
> > <br>
> > There's a well known bug [1][2] (at least well known to me) in the <br>
> > base class of SchemaFactory and XPathFactory in the JDK which causes<br>
> > the default implementation to be picked up rather than the one that <br>
> > should have been found through META-INF/services. The Apache version<br>
> > of these classes (which were donated from Sun Java 5) has had a fix <br>
> > for years. I bet if you put the Apache version of xml-apis.jar in <br>
> > the endorsed directory (or at the front of the bootclasspath) this <br>
> > problem goes away.<br>
> > <br>
> > Thanks.<br>
> > <br>
> > [1] <a href="http://markmail.org/message/rvlroblxyza3xt3v" \
target="_blank"></a><a href="http://markmail.org/message/rvlroblxyza3xt3v" \
target="_blank">http://markmail.org/message/rvlroblxyza3xt3v</a><br> > > [2] <a \
href="http://markmail.org/message/bntj64gxademl5ex" target="_blank"></a><a \
href="http://markmail.org/message/bntj64gxademl5ex" \
target="_blank">http://markmail.org/message/bntj64gxademl5ex</a><br> > > <br>
> > <br>
> > Michael Glavassevich<br>
> > XML Parser Development<br>
> > IBM Toronto Lab<br>
> > E-mail: <a href="mailto:mrglavas@ca.ibm.com" target="_blank"></a><a \
href="mailto:mrglavas@ca.ibm.com" target="_blank">mrglavas@ca.ibm.com</a><br> > \
> E-mail: <a href="mailto:mrglavas@apache.org" target="_blank"></a><a \
href="mailto:mrglavas@apache.org" target="_blank">mrglavas@apache.org</a><br> > \
<br> > > Benson Margulies <<a href="mailto:bimargulies@gmail.com" \
target="_blank">bimargulies@gmail.com</a>> wrote on 10/29/2009 02:00:22 PM:<br> \
> > <br> > > <br>
> > > By the way, is this combination of parsers in a backtrace \
alarming?<br> > > > <br>
> > > at \
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.<br> > > > \
createSAXParseException(ErrorHandlerWrapper.java:195)<br> > > > at \
com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.<br> > > > \
error(ErrorHandlerWrapper.java:131)<br> > > > at \
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.<br> > > > \
reportError(XMLErrorReporter.java:384)<br> > > > at \
com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.<br> > > > \
reportError(XMLErrorReporter.java:318)<br> > > > at \
com.sun.org.apache.xerces.internal.impl.xs.<br> > > > \
XMLSchemaValidator$XSIErrorReporter.<br> > \
reportError(XMLSchemaValidator.java:410)<br> > > > at \
com.sun.org.apache.xerces.internal.impl.xs.<br> > > > \
XMLSchemaValidator.reportSchemaError(XMLSchemaValidator.java:3165)<br> > > > \
at com.sun.org.apache.xerces.internal.impl.xs.<br> > > > \
XMLSchemaValidator.processAttributes(XMLSchemaValidator.java:2630)<br> > > > \
at com.sun.org.apache.xerces.internal.impl.xs.<br> > > > \
XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:2037)<br> > > \
> at com.sun.org.apache.xerces.internal.impl.xs.<br> > > > \
XMLSchemaValidator.startElement(XMLSchemaValidator.java:685)<br> > > > \
at com.sun.org.apache.xerces.internal.jaxp.validation.<br> > > > \
ValidatorHandlerImpl.startElement(ValidatorHandlerImpl.java:549)<br> > > > \
at org.apache.xerces.jaxp.JAXPValidatorComponent$XNI2SAX.<br> > > > \
startElement(Unknown Source)<br> > > > at \
org.apache.xerces.jaxp.JAXPValidatorComponent.<br> > > > \
startElement(Unknown Source)<br> > > > at \
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.<br> > > > \
scanStartElement(Unknown Source)<br> > > > at \
org.apache.xerces.impl.<br> > > > \
XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.<br> > > > \
dispatch(Unknown Source)<br> > > > at \
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.<br> > > > \
scanDocument(Unknown Source)<br> > > > at \
org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)<br> > > > \
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)<br> > > \
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)<br> > \
> > at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)<br> \
> > > at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown \
Source)<br> > > > at \
javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:124)<br> > > > \
<br> > > <br>
> > > On Thu, Oct 29, 2009 at 1:41 PM, Michael Glavassevich <<a \
href="mailto:mrglavas@ca.ibm.com" target="_blank"></a><a \
href="mailto:mrglavas@ca.ibm.com" target="_blank">mrglavas@ca.ibm.com</a><br> > \
> > > wrote:<br> > > > Hi Benson,<br>
> > > <br>
> > > DocumentBuilderFactory and the other JAXP factories use the current \
<br> > > > thread's context ClassLoader by default for locating the <br>
> > > implementation. If for whatever reason the implementation you \
wanted<br> > > > loaded isn't visible to this ClassLoader you'll get \
a different <br> > > > implementation, most likely the default one in the \
JDK. Couldn't <br> > > > tell you how this is occurring in your \
environment. I've never used <br> > > > Tomcat or Maven.<br>
> > > <br>
> > > Thanks.<br>
> > > <br>
> > > Michael Glavassevich<br>
> > > XML Parser Development<br>
> > > IBM Toronto Lab<br>
> > > E-mail: <a href="mailto:mrglavas@ca.ibm.com" target="_blank"></a><a \
href="mailto:mrglavas@ca.ibm.com" target="_blank">mrglavas@ca.ibm.com</a><br> > \
> > E-mail: <a href="mailto:mrglavas@apache.org" target="_blank"></a><a \
href="mailto:mrglavas@apache.org" target="_blank">mrglavas@apache.org</a><br> > \
> > <br> > > > Benson Margulies <<a \
href="mailto:bimargulies@gmail.com" target="_blank">bimargulies@gmail.com</a>> \
wrote on 10/29/2009 12:35:42 PM:<br> > > > <br>
> > > <br>
> > > > I have some code that uses DocumentBuilderFactory etc. (JAXP) to \
<br> > > > > parse a document with W3C schema validation.<br>
> > > > <br>
> > > > My unit tests work fine with Xerces in the classpath.<br>
> > > > <br>
> > > > When the business is all packaged into a webapp and deployed in \
<br> > > > > tomcat (via mvn tomcat:run), the validation fails with bogus \
error, <br> > > > > and the backtrace shows that I'm using whatever \
nasty version of <br> > > > > JAXP is sitting in the JVM. Short of \
calling <br> > > > > DocumentBuilderFactoryImpl, can anyone tell me what \
I'm doing wrong?<br> > > > > The xerces Jar is in the WAR file in the \
right place.</tt></p></div></blockquote></div></div></div></blockquote></div><br> \
</div></div></blockquote></div><br>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic