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 "Michael Woinoski (JIRA)" <ax...@ws.apache.org> on 2004/11/05 15:29:32 UTC
[jira] Created: (AXIS-1651) When fault defines element named "message", WSDL2Java generates method getMessage1
When fault defines element named "message", WSDL2Java generates method getMessage1
-----------------------------------------------------------------------------------
Key: AXIS-1651
URL: http://nagoya.apache.org/jira/browse/AXIS-1651
Project: 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://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXIS-1651) When fault defines element named "message", WSDL2Java generates method getMessage1
Posted by "Michael Woinoski (JIRA)" <ax...@ws.apache.org>.
[ http://nagoya.apache.org/jira/browse/AXIS-1651?page=comments#action_55100 ]
Michael Woinoski commented on AXIS-1651:
----------------------------------------
Possible fix: in org\apache\axis\wsdl\toJava\JavaBeanFaultWriter.java, remove 'temp.add("message");' from the static initializer?
> When fault defines element named "message", WSDL2Java generates method getMessage1
> ----------------------------------------------------------------------------------
>
> Key: AXIS-1651
> URL: http://nagoya.apache.org/jira/browse/AXIS-1651
> Project: 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://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Resolved: (AXIS-1651) When fault defines element named "message", WSDL2Java generates method getMessage1
Posted by "Davanum Srinivas (JIRA)" <ax...@ws.apache.org>.
[ 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