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(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.axis.utils.BeanPropertyDescriptor.set(BeanPropertyDescriptor.java:117)
... 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,
however.
Can I ask about something? It seems from the comments on
http://wiki.apache.org/geronimo/Deployment#head-754164850f38c1ecdaf6b8ed894cb192bc36c5f4-2
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,
Toby
