Nightmarish XML Classloader issue with Tomcat

Thread view:

flarosa - 29 Aug 2007 20:33 GMT

Hi,

I'm dealing with an unknown version of Tomcat running under JDK 1.6.

While I'm sure I can figure out what version of Tomcat I have,
altering it is not an option because I am a developer in a large
organization and the code I write must deploy correctly on many other
machines, all of which are running the same instance of Tomcat. I am
not able to change this environment.

I wrote some XML parsing code that uses the normal classes defined in
JDK 1.6, such as javax.xml.parsers.DocumentBuilderFactory, etc. When I
compile the code against JDK 1.6 it seems fine, but when I deploy it
to Tomcat I get java.lang.NoSuchMethod errors when calling functions
such as Node.getTextContent().

My guess is that the classpath in Tomcat contains some pre-JDK 1.4
definition of the javax.xml classes that don't conform to what I'm
compiling against. I have never done XML parsing with anything less
than JDK 1.4 or anything other than the interfaces provided by Sun in
the standard JDKs. So I have no idea what it is I'm dealing with here.

How can I change my source code in such a way that I get the JDK 1.6
classes instead of these old versions from Tomcat?

Thanks,
Frank

Reply to this Message

Mike Schilling - 29 Aug 2007 21:41 GMT

> Hi,
>
[quoted text clipped - 20 lines]
> How can I change my source code in such a way that I get the JDK 1.6
> classes instead of these old versions from Tomcat?

Assuming that Tomcat is running under Java 1.6 (if not, there's no hope of
finding the 1.6 classes), what's happening is that the logic in
DocumentBulderFactory.newInstance() that looks for a DocumentBulderFactory
implementation isn't finding the implementation you're expecting. See its
javadoc for how it finds one. You can either

1. Modify your application so that you one you're expecting is found first,
or
2. Use the one you want explicitly instead of going through
DocumentBulderFactory.newInstance()

Note that there are some issues with doing 1. For instance, setting a
system property will affect every application in Tomcat, since system
properties are JDK-wide, so that's not a good idea.

Reply to this Message

flarosa - 31 Aug 2007 21:37 GMT

Thanks for the reply. I was able to get the class I wanted to load by
modifying that system property, but it doesn't help because my class
(the one containing the code where I'm trying to parse XML) still
thinks DocumentBuilderFactory refers to the older interface, hence I
still get a ClassCastException before my class even loads into memory.
I would guess that I'd have to somehow modify or replace the
classloader to fix this - I'm not up for it.

Fortunately I was able to work around the issue by using a different
way to get at the text in the node.

It's a shame that problems like this still exist as legacies of bad
decisions in the past. When enough of them pile up, that's when people
start thinking about moving to a new platform.

Frank

On Aug 29, 3:41 pm, "Mike Schilling" <mscottschill...@hotmail.com>
wrote:

> > Hi,
>
[quoted text clipped - 37 lines]
>
> - Show quoted text -

Reply to this Message

Mike Schilling - 31 Aug 2007 21:57 GMT

> Thanks for the reply. I was able to get the class I wanted to load by
> modifying that system property, but it doesn't help because my class
[quoted text clipped - 3 lines]
> I would guess that I'd have to somehow modify or replace the
> classloader to fix this - I'm not up for it.

That doesn't make sense to me. DocumentBuilderFactory will be loaded by the
system classloader, and all other classloaders should defer to it. Are you
sure that Tomcat is running under 1.6?

Anyway, something else you can do (that's simple) is not use the
DocumentBuilderFactory interface at all. Just instantiate the
implementation you want, by its name, and go from there.

Reply to this Message

Nightmarish XML Classloader issue with Tomcat

Free Magazines