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 "Ping Liu (Commented) (JIRA)" <ji...@apache.org> on 2012/01/22 20:46:39 UTC
[jira] [Commented] (AXIS2-2811) Assumption that message label and
message direction are synonymous
[ https://issues.apache.org/jira/browse/AXIS2-2811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13190748#comment-13190748 ]
Ping Liu commented on AXIS2-2811:
---------------------------------
Could you provide a sample WSDL? To verify this patch, I guess we have to see how the code generator fails on the sample WSDL first without the patch and then is able to successfully generate code after the patch is applied.
> Assumption that message label and message direction are synonymous
> ------------------------------------------------------------------
>
> Key: AXIS2-2811
> URL: https://issues.apache.org/jira/browse/AXIS2-2811
> Project: Axis2
> Issue Type: Bug
> Components: codegen
> Reporter: Peter Danielsen
> Assignee: Keith Godwin Chapman
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org