I've come across an Axis problem with Java 1.4. The 1.4 JDK introduces a couple methods in the Exception class:
public Throwable getCause()
public StackTraceElement[] getStackTrace()

Suppose the Java interface you're converting to a web service throws exceptions. Since the above methods are public, they're picked up by Java2WSDL for Exception, RemoteException and any descendant thereof. So Java2WSDL produces the following warnings:

org.apache.axis.wsdl.fromJava.Types isBeanCompatible
WARNING: The class java.lang.Throwable is defined in a java or javax package and
cannot be converted into an xml schema type. An xml schema anyType will be use
d to define this class in the wsdl file.
org.apache.axis.wsdl.fromJava.Types isBeanCompatible
WARNING: The class java.lang.StackTraceElement is defined in a java or javax pac
kage and cannot be converted into an xml schema type. An xml schema anyType wil
l be used to define this class in the wsdl file.

I notice that, in the generated WSDL file, the references to Throwable, StackTraceElement, and array of StackTraceElement mention a namespace, tns3, which in my system doesn't exist.

Next I run WSDL2Java. It throws the following exception:
java.io.IOException: Type StackTraceElement is referenced but not defined.
at org.apache.axis.wsdl.symbolTable.SymbolTable.checkForUndefined(SymbolTable.java:496)
at org.apache.axis.wsdl.symbolTable.SymbolTable.add(SymbolTable.java:396)
at org.apache.axis.wsdl.symbolTable.SymbolTable.populate(SymbolTable.java:382)
at org.apache.axis.wsdl.symbolTable.SymbolTable.populate(SymbolTable.java:367)
at org.apache.axis.wsdl.gen.Parser$WSDLRunnable.run(Parser.java:246)
at java.lang.Thread.run(Thread.java:536)

The only way I have found to prevent this problem is to take the WSDL file generated by Java2WSDL and strip any references to the Throwable and StackTraceElements. I do this hack during my build using a DOM parser.

I also have a .NET client that needs the Axis web service's WSDL. Since the dynamic WSDL obtained through the ?wsdl URL parameter will have the same dreaded Throwable and StackTraceElements belonging to the same dreaded undefined namespace, I have to feed .NET my hacked static WSDL.

Ironically, exception throwing works. At the end of this message is the content of a sample SOAP response containing a fault corresponding to the original server exception. The response even contains a stack trace in the fault detail.

So with the hack, everything works. Just, it's irritating that, without this hack, Axis seemingly can't produce a valid WSDL in the common circumstance of needing to throw exceptions in Java 1.4.
===============================================================================
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
<soapenv:Body>
<soapenv:Fault>
<faultcode>soapenv:Server.userException</faultcode>
<faultstring>This is a test exception.</faultstring>
<detail>
<ns1:stackTrace xmlns:ns1="http://xml.apache.org/axis/";>This is a test exception.
at foo.bar.ApplicationBean.testException(ApplicationBean.java:225)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
...
</ns1:stackTrace>
</detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>

Reply via email to