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
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 wrote:
> Sounds eriely like a problem I was having deploying my CXF app to WAS
> 6.1...[1]. M
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
On 2009-10-29, at 2:02 PM, Micha
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
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, thoug
Would that require xml-apis-1.4.x?
On Thu, Oct 29, 2009 at 2:41 PM, Michael Glavassevich
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 yo
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 in
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 implementati
You probably need to put Xerces into the Tomcat lib directory, or some
other directory that serves as an "endorsed" override to the JDK's
version (or some other JAXP that gets loaded before your webapp).
In different appservers, there are different conventions for whether the
container's class
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
wrote:
> I'
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
Apa
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 Apach
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
Michael,
Thanks. Based on this I forced the use of the correct impl by calling
DocumentBuilderImpl and also XMLSchemaFactory. And the problem did not go
away. So while there may be classloader issues that caused me to use the
wrong parser, the right parser also rejects this file, but only inside a
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
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, a
16 matches
Mail list logo
