You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Davanum Srinivas (JIRA)" <ax...@ws.apache.org> on 2005/07/27 22:28:23 UTC

[jira] Resolved: (AXIS-1651) When fault defines element named "message", WSDL2Java generates method getMessage1

     [ http://issues.apache.org/jira/browse/AXIS-1651?page=all ]
     
Davanum Srinivas resolved AXIS-1651:
------------------------------------

    Resolution: Won't Fix

Michael,

I don't think we can handle this now unless someone can submit a patch (and makes sure that "ant clean all-tests" work)  to make this happen. what you mentioned is just the tip of the iceberg.

thanks,
dims

> When fault defines element named "message", WSDL2Java generates method getMessage1
> ----------------------------------------------------------------------------------
>
>          Key: AXIS-1651
>          URL: http://issues.apache.org/jira/browse/AXIS-1651
>      Project: Apache Axis
>         Type: Bug
>     Versions: 1.2RC1
>  Environment: Win2K Pro, Axis 1.2RC1
>     Reporter: Michael Woinoski
>     Priority: Minor

>
> For a wrapped/literal operation, if a fault type defines an element named "message":
>       <complexType name="TestException">
>         <sequence>
>           <element name="message" nillable="true" type="xsd:string"/>
>         </sequence>
>       </complexType>
> the exception generated by WSDL2Java defines a new field named message1 and a method named getMessage1. This results in "unnatural" client code:
>     catch (TestException ex) {   
>         log(ex.getMessage1());  
>     }
>     
> I'm not sure if this is a bug or a wish list item, but the generated exception class could use the superclass's message field instead of generating a new field. That would permit the use of getMessage() as usual. If that's not possible because of the way the bean is deserialized, the generated exception class could simply generate a getMessage override:
>     public String getMessage() {
>         return getMessage1();
>     }
> The superclass message field will always be null anyway, so we're not losing anything with this approach.            

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira