On 3/25/03 08:55 PM [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: The reason is simple in my case: Bea uses an EJB Classloader to load a war archive, and I have a common shared jar referenced from the ejb-jar and the war archive in their Manifest.MF. A patched Axis Servlet is part of this common jar, and thus said it will be loaded through the ejb classloader directly. You might argue that I could split my jars easily. But this isn't going to work. Build management for reusable j2ee components is a nightmare, and the best way to resolve dependencies is using shared jars across deployed war and ejb jar files ;)
Jens, I look forward to contribution in this area, which sounds like it comes from testing as well as just the fix. I dont see any testing for complex Axis-EJB bindings right now.
Regarding classloaders, servlet API 2.3 specifies that classes in the WAR come first, before parent classloader stuff. Tomcat has a switch to disable this behaviour, Jboss+Jetty has a switch to enable it. So server config defaults may be part of the problem (and solution). Since axis nominally targets servlet2.2, we cannot mandate the WAR classloader first solution.
Setting a context classloader could be a bad idea, it could really break the app server, its thread pools and its resource access. It seems Axis already does something like that, see "AXIS classloaders breaking J2EE application isolation" on axis-user. I will try dig into that this evening ...
I think they were doing something very contrived there.
