[
https://issues.apache.org/jira/browse/AXIS2-2811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Danielsen updated AXIS2-2811:
-----------------------------------
Attachment: AxisServiceBasedMultiLanguageEmitter.patch.txt
WSDL20ToAxisServiceBuilder.patch.txt
AxisMessage.patch.txt
Attached are patches that will allow the message label to make it all the way
through the codegen process to the Emitter templates.
AxisMessage - adds a new field "label" with a setter and getter.
WSDL20ToAxisServiceBuilder - sets the AxisMessage's label and uses
messageReference.getDirection() to classify a message as input or output,
rather than trying to infer it from its label. Relying on the label won't work
if a new MEP is introduced that doesn't follow the existing pattern.
AxisServiceBasedMultiLanguageEmitter - adds "label" attribute to "input" and
"output" elements in the Documents provided to the emitter templates.
> 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
> 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]
