[
https://issues.apache.org/jira/browse/AXIS2-2811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davanum Srinivas updated AXIS2-2811:
------------------------------------
Fix Version/s: 1.3
> Assumption that message label and message direction are synonymous
> ------------------------------------------------------------------
>
> Key: AXIS2-2811
> URL: https://issues.apache.org/jira/browse/AXIS2-2811
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: codegen
> Reporter: Peter Danielsen
> Assignee: Keith Godwin Chapman
> Fix For: 1.3
>
> Attachments: AxisMessage.patch.txt,
> AxisServiceBasedMultiLanguageEmitter.patch.txt,
> WSDL20ToAxisServiceBuilder.patch.txt
>
>
> It looks like there's an assumption that message label and message direction
> will always be synonymous.
> I've been trying to create an Axis2 code generation template that would use
> the value of a message's "messageLabel" attribute in a WSDL2 document.
> Unfortunately, that value doesn't appear in the Document created by the
> AxisServiceBasedMultiLanguageEmitter. I looked into this a bit and found
> that the actual value of the message label is lost in sub-class
> implementations of the abstract AxisOperation method
> addMessage(AxisMessage, String)
> called by WSDL20ToAxisServiceBuilder.createAxisMessage().
> WSDL20ToAxisServiceBuilder.populateOperations exhibits the assumption in the
> for loop that iterates over the InterfaceMessageReferences.
> If I'm reading the WSDL2 spec right, the message exchange pattern defines the
> label constraints for its messages. So, it seems like the classification
> should be based on the message reference's getDirection(). While what's there
> now may work, it won't if a new MEP is defined. I think getDirection() should
> work regardless.
> WSDL2's ability to accommodate new MEPs also calls into question Axis2's
> practice of mapping MEP strings to constant integer values throughout the
> code. Why not just stick with the MEP strings to support extensibility now?
--
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]
