axis-java-dev mailing list archives

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


Amila Chinthaka Suriarachchi updated AXIS2-2702:

if there are more than one fault message uses the same element (which is go inside the detail
Element of the soap body ) then at the receiving side we can not determine the original Exception
type it throws. This details is not present in the soap messag. The only way to solve this
problem is to use fault Action (with addressing) to resolve the original fault message.
Since this is not a common case and Axis2 still does not properly support fault actions. I
downgreade this isuue to be fixed it on next release.

> 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: Amila Chinthaka Suriarachchi
>            Priority: Blocker
>             Fix For: 1.3
>         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