axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amila Chinthaka Suriarachchi (JIRA)" <>
Subject [jira] Commented: (AXIS2-2702) Codegen issues for operation with multiple faults of same type
Date Tue, 19 Jun 2007 01:15:25 GMT


Amila Chinthaka Suriarachchi commented on AXIS2-2702:

The original patch you send has created the fault message Qname using the operation name space.
This is not correctl always. The real problem is axis2 does not have the message qname and
it keeps only the message name. 
As given in the second patch we can not change the namespace or the local name since these
are the two properties which is used to identify the correct exception class. See the Axis2Fault
handling code in the generated stub with -s. 
At the stub it determines the Exception class using the qname of the received message. Actually
there is no other way around. As a result of the the correct Exception message class can not
be determined at the stub if two exception classes have the same element. 
For your problem the correct fix is to keep the whttp code in Axis2Fault and determine the
correct exception using that.

> Codegen issues for operation with multiple faults of same type
> --------------------------------------------------------------
>                 Key: AXIS2-2702
>                 URL:
>             Project: Axis 2.0 (Axis2)
>          Issue Type: Bug
>          Components: codegen
>            Reporter: Peter Danielsen
>            Assignee: Keith Godwin Chapman
>            Priority: Blocker
>         Attachments: AxisServiceBasedMultiLanguageEmitter.2.patch.txt, AxisServiceBasedMultiLanguageEmitter.patch.txt,
> 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:
For additional commands, e-mail:

View raw message