axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Danielsen (JIRA)" <>
Subject [jira] Created: (AXIS2-2702) Codegen issues for operation with multiple faults of same type
Date Wed, 23 May 2007 22:16:16 GMT
Codegen issues for operation with multiple faults of same type

                 Key: AXIS2-2702
             Project: Axis 2.0 (Axis2)
          Issue Type: Bug
          Components: codegen
            Reporter: Peter Danielsen

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