Can someone else confirm that this has NOT been fixed? I am seeing this behaviour with 1.4 using the RC.
Thanks, Jess Mitch, This has already been fixed. Please try latest nightly build. Thanks, dims >> Mitch, >> >> Can you file a bug for this with a small test case? >> >> Including a patch with the bug will increase the odds of the fix making 1.1 by an >order of magnitude! >> >> Thanks. >> -- >> Tom Jordahl >> Macromedia Server Development >> >> >> >> -----Original Message----- >> From: Mitch Gitman [mailto:[EMAIL PROTECTED]] >> Sent: Monday, December 23, 2002 12:27 PM >> To: [EMAIL PROTECTED] >> Subject: Java 1.4 issue >> >> >> 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> ===== Davanum Srinivas - http://xml.apache.org/~dims/ __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- ======================================= Jess Sightler Senior Developer Exim Technologies 131 Falls Street Greenville SC 29601 Phone: 864-679-4651 =======================================
