On 3/27/03 07:37 PM Steve Loughran <[EMAIL PROTECTED]> wrote: > > A JSP page that you drop in anywhere and generates an XML report is a good > way to do this...I could even imagine it becomes part of the happyaxis > config probing over time.
I have spend a little bit more time on this topic. My observations: A simple JSP sounds very good, but does not reveal the needed information. It is important to collect classloader details during a typical webservice call. First stage I added a logger category "org.apache.axis.LOADING", added a few log statements and used a simple web service call to create the output. This works very good for now, but log4j does have its limits. What I am looking for is a way to collect information for a certain period of time (a group of WS calls) and use a JSP to fetch those data, and clear them afterwards. I think there are two different solutions: Write a custom log4j appender or introduce some kind of simple "collection framework". Extending log4j will be straight forward, but will create deployment problems on platforms which rely on it (e.g. JBoss). A static collection class as part of axis.jar looks way better, but might break the current design (since log4j is used to collect response times already). What do you think? I have been able to test the deployment strategies on a few platforms only: Bea Weblogic 6.2, JBoss 3.0.4/JBoss 3.0.6, Orion Server 2.0 (Oracle IAS is based on OrionServer 1.5.x) using MacOSX. A short recap: Jboss 3.0.4 produced in certain situations ClasscastExceptions for Axis -> EJB calls using custom types. This is caused by referenced libraries, it disappeared using 3.0.6. (JBoss internal classloader hierarchy changed with 3.0.5) OrionServer 2.0 was working fine, until I used two axis war archives containing all axis libraries. Calling a WebService in war archive A works as expected, calling the same WebService in war archive B causes a ClassCastException in BaseDeserializerFactory.createFactory(). Somehow ClassUtils.forName() in WSDDTypeMapping returns a Serializer Class loaded through the ClassLoader of the first WebService call. Currently I am not sure if this is a OrionServer or Axis problem. I have been running into a few BEA deployment problems, they were already reported on axis-user. I will report a bug (Classpath in Manifest.MF and dots in library names). Bea behaves as expected, with problems finding custom WSDD Providers using a certain EAR deployment strategy. I have to extend the WSDD Provider test to be more specific. So far, Jens
