[
https://issues.apache.org/jira/browse/AXIS2-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Danielsen reopened AXIS2-2702:
------------------------------------
Amila,
Thank you for addressing this issue. I see that you modified the patch I
submitted.
I'm running into a problem when using the committed version with my own
templates. My templates generate a method for each "fault/param", rather than
one shared by all. When this happens with the committed version and the
http-faults.wsdl file, the code ends up with three identical methods in the
generated CallbackHandler class, so it won't compile.
The submitted version had faultToTypeMap mapping faultQNames to
faultMessage.getElementQName to address the situation where multiple faults in
the HTTP binding had the same type. The committed version changed its name to
faultElementQNameMap, which is ok, and most of the code changes required
because of that are ok, except in one place. In the submitted version,
getFaultParamElements(..) used the fault to set the <param>'s "namespace" and
"localname" attributes. The committed version, however, sets them from the
fault's element's type. When the fault's element's type is used, the
application loses the ability to distinguish the faults from one another,
because the generated code is looking only at their types. In
http-faults.wsdl, all the faults have the same type. The WSDL source document
used the "whttp:code" attribute on the fault binding reference to distinguish
the faults.
I'm not a SOAP expert, so I may be wrong, but this seems like an important
difference between the WSDL2 SOAP and HTTP bindings: in SOAP we only have to
worry about the envelope in the body of the HTTP message, but in the HTTP
binding we have to worry about the body and other parts like the headers and
status code.
Can you please take another look at this?
Peter
> 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: Keith Godwin Chapman
> Priority: Blocker
> Attachments: 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]
