axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Schumann <>
Subject Resource Access
Date Thu, 27 Mar 2003 17:50:22 GMT
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:


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.

PS: I am not sure if we fix commons-discovery problems here ...


View raw message