geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From toby cabot <>
Subject Re: problem with axis/xerces and web apps
Date Mon, 31 Jan 2005 21:01:27 GMT
Thanks for your help, David.  I got things working, but it took a fair
bit of messing around.  It seems that Axis really likes to be loaded
by the same classloader as the code that it's working with.  For
example, when I used the Axis that's built into Geronimo I got

Caused by: java.lang.IllegalArgumentException: object is not an instance of declaring class
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(
        at java.lang.reflect.Method.invoke(
        at org.apache.axis.utils.BeanPropertyDescriptor.set(

... when Axis tried to load one of my classes (which are in the war
file).  This looks like a similar problem to the Xerces problem that
started this thread (i.e. can't load a class using the context
classloader and then cast it).  So in the end I've got Axis and Castor
in the war file, and context-priority-classloader=true and that works
for me.  I'm using Geronimo's commons-logging and commons-discovery,

Can I ask about something?  It seems from the comments on
and the default "false" value of context-priority-classloader that
Geronimo's preferred configuration is to load classes from the
container-wide classloader first, then the war file classloader.  In
the Servlet spec it's "recommended" that classes be loaded from the
war first.  Is this a case where you guys think that the spec is
off-base or just an oversight?  It doesn't really matter since it's a
recommendation rather than a requirement, but it would be cool if
Geronimo's default could follow the spec's recommendation.

Again, thanks for your help on this,

View raw message