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)" <ji...@apache.org> on 2007/08/06 15:58:03 UTC

[jira] Updated: (AXIS2-2702) Codegen issues for operation with multiple faults of same type

     [ https://issues.apache.org/jira/browse/AXIS2-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Davanum Srinivas updated AXIS2-2702:
------------------------------------

    Fix Version/s:     (was: 1.3)

> Codegen issues for operation with multiple faults of same type
> --------------------------------------------------------------
>
>                 Key: AXIS2-2702
>                 URL: https://issues.apache.org/jira/browse/AXIS2-2702
>             Project: Axis 2.0 (Axis2)
>          Issue Type: Bug
>          Components: codegen
>            Reporter: Peter Danielsen
>            Assignee: Amila Chinthaka Suriarachchi
>            Priority: Critical
>         Attachments: AxisServiceBasedMultiLanguageEmitter.2.patch.txt, AxisServiceBasedMultiLanguageEmitter.patch.txt, http-faults.wsdl
>
>
> I ran into several issues when examining the output of Axis2 codegen on 
> the attached WSDL2 file.  The WSDL uses the HTTP binding for one 
> interface with one operation containing three faults.  All faults have the same type. 
> The issues are:
> 1. In the Skeleton, the operation's method has a "throws" list that
> includes the same exception three times.
> 2. In the Stub, 
>   a. the "fromOM" method has three identical "if" statements,
>   b. the "populateFaults" method has three identical additions to
>      the HashMaps.
>   c. the class contains SOAP-related code even though the WSDL is
>      using the HTTP binding.
> 3. In the CallbackHandler, 
>   a. there is a single "receiveError(Exception e)" method even though 
>      there are three different faults.  It's unclear how sub-classes 
>      will be able to distinguish the three faults.
>   b. It seems like it would be more flexible for the CallbackHandler
>      to be an interface, rather than an abstract class.  The decision
>      to include a "clientData" member seems like it should be up to
>      the application.
> Most of the issues stem from AxisServiceBasedMultiLanguageEmitter's
> use of the fullyQualifiedClassMap.  It's currently mapping the fault's
> "element" attribute to a Java class name.  When multiple faults have the same
> "element" value, they all end up with the same class name resulting
> in the duplication identified above.
> I'm attaching a patch that fixes issues 1, 2a, and 2b by 
> 1. changing the purpose of fullyQualifiedClassMap to be a mapping 
> from fault name to a Java class name.
> 2. adding a separate faultToTypeMap that maps fault name to "element"
> type name.
> 3. updating methods within the class to use these to generate code
> that preserves the individual faults.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org