Return-Path: Delivered-To: apmail-ws-axis-user-archive@ws.apache.org Received: (qmail 6237 invoked by uid 500); 13 Feb 2003 19:51:02 -0000 Mailing-List: contact axis-user-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-user@ws.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-user@ws.apache.org Received: (qmail 6222 invoked from network); 13 Feb 2003 19:51:01 -0000 To: axis-user@ws.apache.org Cc: axis-dev@ws.apache.org, axis-user@ws.apache.org Subject: Re: MAJOR Exception problems in RC1 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: pchoudhu@manu.com Date: Thu, 13 Feb 2003 14:51:03 -0500 X-MIMETrack: Serialize by Router on Notesgate2/MANUGISTICS(Release 5.0.11 |July 24, 2002) at 02/13/2003 02:51:05 PM, Serialize complete at 02/13/2003 02:51:05 PM Content-Type: multipart/alternative; boundary="=_alternative 006D308385256CCC_=" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N This is a multipart message in MIME format. --=_alternative 006D308385256CCC_= Content-Type: text/plain; charset="us-ascii" I too see the problem using 1.4 and the RC. Thanks, Paromita Jess Sightler 02/13/2003 02:46 PM Please respond to axis-user To: axis-user@ws.apache.org cc: axis-dev@ws.apache.org Subject: MAJOR Exception problems in RC1 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:mgitman@usa.net] >> Sent: Monday, December 23, 2002 12:27 PM >> To: axis-user@xml.apache.org >> 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. >> =============================================================================== >> >> > xmlns:xsd="http://www.w3.org/2001/XMLSchema"; >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> >> >> >> soapenv:Server.userException >> This is a test exception. >> >> 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) >> ... >> >> >> >> >> ===== 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 ======================================= --=_alternative 006D308385256CCC_= Content-Type: text/html; charset="us-ascii"
I too see the problem using 1.4 and the RC.

Thanks,
Paromita



Jess Sightler <jsightler@eximtechnologies.com>

02/13/2003 02:46 PM
Please respond to axis-user

       
        To:        axis-user@ws.apache.org
        cc:        axis-dev@ws.apache.org
        Subject:        MAJOR Exception problems in RC1



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:mgitman@usa.net]
>> Sent: Monday, December 23, 2002 12:27 PM
>> To: axis-user@xml.apache.org
>> 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
=======================================

--=_alternative 006D308385256CCC_=--