You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Peter Danielsen (JIRA)" <ji...@apache.org> on 2007/05/24 00:16:16 UTC
[jira] Created: (AXIS2-2702) Codegen issues for operation with
multiple faults of same type
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
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Assigned: (AXIS2-2702) Codegen issues for operation with
multiple faults of same type
Posted by "Davanum Srinivas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Davanum Srinivas reassigned AXIS2-2702:
---------------------------------------
Assignee: Keith Godwin Chapman
> 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
> Assigned To: Keith Godwin Chapman
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Updated: (AXIS2-2702) Codegen issues for operation with
multiple faults of same type
Posted by "Amila Chinthaka Suriarachchi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
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: 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: Blocker
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-2702) Codegen issues for operation with
multiple faults of same type
Posted by "Peter Danielsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506249 ]
Peter Danielsen commented on AXIS2-2702:
----------------------------------------
Amila,
Running the committed version on http-faults.wsdl produces a Stub whose populateFaults method has three sets of Map put calls with the same key and different values. Each set is overwriting the results of the previous one, so only the last set matters -- won't every fault that occurs will look like a ServiceTemporarilyUnavailable? An application using the Stub will only ever see that fault even though the others may be occurring, too. I think this is because the AxisFault handling is looking only at the type of the data contained in the fault.
I took a closer look at the generated MessageReceiver and found the problem there also. It's invokeBusinessLogic method has a catch for each fault, which is expected, but in each case it's setting the msgContext's FAULT_NAME property to the same value, which is the fault's type, rather than it's name. At run time, AxisServlet uses the FAULT_NAME to look up the fault in AxisBindingOperation and get the HTTP status code. If it does find one with that name, I think we'll still have lost the original fault identity.
It looks like the cause of the MessageReceiver problem is AxisServiceBasedMultiLanguageEmitter's getUniqueListofFaultsofMep(Document, String) method in its setting of the variable "exceptionName". If it's set to "key", the problem goes away.
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.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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Updated: (AXIS2-2702) Codegen issues for operation with
multiple faults of same type
Posted by "Peter Danielsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Danielsen updated AXIS2-2702:
-----------------------------------
Attachment: AxisServiceBasedMultiLanguageEmitter.patch.txt
http-faults.wsdl
Run Axis2 codegen on http-faults.wsdl with the settings listed in the file, to see the issues mentioned in this JIRA. Apply the patch contained in AxisServiceBasedMultiLanguageEmitter.patch.txt to org.apache.axis2.wsdl.codegen.emitter.AxisServiceBasedMultiLanguageEmitter.java to see the proposed changes.
> 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
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Resolved: (AXIS2-2702) Codegen issues for operation with
multiple faults of same type
Posted by "Amila Chinthaka Suriarachchi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Amila Chinthaka Suriarachchi resolved AXIS2-2702.
-------------------------------------------------
Resolution: Fixed
fixed the issue with some modifications to the given patch.
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Updated: (AXIS2-2702) Codegen issues for operation with
multiple faults of same type
Posted by "Peter Danielsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Danielsen updated AXIS2-2702:
-----------------------------------
Attachment: AxisServiceBasedMultiLanguageEmitter.2.patch.txt
Attached is another patch that addresses the situation when I use my templates. I don't believe it causes harm when the Axis2-supplied templates are used.
> 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.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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-2702) Codegen issues for operation with
multiple faults of same type
Posted by "Keith Godwin Chapman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498931 ]
Keith Godwin Chapman commented on AXIS2-2702:
---------------------------------------------
Hi Peter,
Looking at the desciption you've given it looks like the problem prevails in WSDL 1.1 too if all afults refer to the same message element. I asked Amila (who is heavily involved in codegen) to have a look at your patch and commiy it.
Thanks for your observations and patch.
> 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
> Assigned To: Keith Godwin Chapman
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Assigned: (AXIS2-2702) Codegen issues for operation with
multiple faults of same type
Posted by "Keith Godwin Chapman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Keith Godwin Chapman reassigned AXIS2-2702:
-------------------------------------------
Assignee: Amila Chinthaka Suriarachchi (was: Keith Godwin Chapman)
This seems to be your domain.
> 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: Blocker
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-2702) Codegen issues for operation with
multiple faults of same type
Posted by "Amila Chinthaka Suriarachchi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505991 ]
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: 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.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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Reopened: (AXIS2-2702) Codegen issues for operation with
multiple faults of same type
Posted by "Peter Danielsen (JIRA)" <ji...@apache.org>.
[ 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Updated: (AXIS2-2702) Codegen issues for operation with
multiple faults of same type
Posted by "Amila Chinthaka Suriarachchi (JIRA)" <ji...@apache.org>.
[ 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Updated: (AXIS2-2702) Codegen issues for operation with
multiple faults of same type
Posted by "Jaliya Ekanayake (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jaliya Ekanayake updated AXIS2-2702:
------------------------------------
Priority: Blocker (was: Major)
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Updated: (AXIS2-2702) Codegen issues for operation with
multiple faults of same type
Posted by "Davanum Srinivas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Davanum Srinivas updated AXIS2-2702:
------------------------------------
Fix Version/s: (was: 1.3)
> 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
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org