I have been thinking a bit about Steve's comments on getting the class and resource loading straight, and I agree, there is testing required before looking at a fix.
While dealing with the Orion Server issue I came to the conclusion that the only way to get it right is to build up some kind of test suite and run it on different app servers. The actual test should return the classloader hierarchy for several important classes/resources: server-config.wsdd AxisServlet.java AxisServer.java WSDDProvider.java A custom Provider. A custom Handler. A custom AxisServlet. All WebService Stubs/Skeletons and and least one complex type class (a value object, for instance). More TBD. The following deployment strategies should be tested: 1. Deploy axis war as exploded war and war archive. 2. Deploy axis war in a exploded ear and ear archive. 3. Enable/disable load-on-startup for the axis servlet. 4. Refer to axis.jar and web service classes through Manifest.MF or add the classes to the archives directly. 5. Add an EJB-Jar to the EAR. Although 3 & 5 should not be an axis problem it reveals details of the application server classloader hierarchy and its side effects (e.g. Bea Weblogic uses EJB Classloaders to load war archives). I have started to work on a classloader debug web service and a few ant targets which create the archives as described above, right now there are almost 15 ways to deploy this web service. I don't see a way to run automatic tests for all these cases, but with a few lines of documentation everyone who runs into problems should be able to produce a report. Jens PS: I am not sure if we fix commons-discovery problems here ...
