[
https://issues.apache.org/jira/browse/AXIS2-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amila Chinthaka Suriarachchi updated AXIS2-2702:
------------------------------------------------
Priority: Critical (was: Blocker)
> 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
> Fix For: 1.3
>
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
