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/06/18 04:51:27 UTC

[jira] Created: (AXIS2-2811) Assumption that message label and message direction are synonymous

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


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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


[jira] Commented: (AXIS2-2811) Assumption that message label and message direction are synonymous

Posted by "Amila Chinthaka Suriarachchi (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/AXIS2-2811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506663 ] 

Amila Chinthaka Suriarachchi commented on AXIS2-2811:
-----------------------------------------------------

is the direction attribute is a manadatory one? can you attach a sample wsdl?
I am not much familier with the wsdl 2.0 why there are two attributes messageLable and direction if they mean same?

> 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: Amila Chinthaka Suriarachchi
>         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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


[jira] Commented: (AXIS2-2811) Assumption that message label and message direction are synonymous

Posted by "Amila Chinthaka Suriarachchi (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/AXIS2-2811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506667 ] 

Amila Chinthaka Suriarachchi commented on AXIS2-2811:
-----------------------------------------------------

I checked with some wsdl 2.0 documents they contain the messageLabel but not the direction.

> 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: Amila Chinthaka Suriarachchi
>         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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


[jira] Updated: (AXIS2-2811) Assumption that message label and message direction are synonymous

Posted by "Davanum Srinivas (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/AXIS2-2811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Davanum Srinivas updated AXIS2-2811:
------------------------------------

    Assignee: Amila Chinthaka Suriarachchi

> 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: Amila Chinthaka Suriarachchi
>         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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


[jira] Updated: (AXIS2-2811) Assumption that message label and message direction are synonymous

Posted by "Davanum Srinivas (JIRA)" <ji...@apache.org>.
     [ 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:     (was: 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
>         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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


[jira] Updated: (AXIS2-2811) Assumption that message label and message direction are synonymous

Posted by "Davanum Srinivas (JIRA)" <ji...@apache.org>.
     [ 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


[jira] Updated: (AXIS2-2811) Assumption that message label and message direction are synonymous

Posted by "Peter Danielsen (JIRA)" <ji...@apache.org>.
     [ 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


[jira] Assigned: (AXIS2-2811) Assumption that message label and message direction are synonymous

Posted by "Amila Chinthaka Suriarachchi (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/AXIS2-2811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Amila Chinthaka Suriarachchi reassigned AXIS2-2811:
---------------------------------------------------

    Assignee: Keith Godwin Chapman  (was: Amila Chinthaka Suriarachchi)

Keith can you please evaluate this patch and commit it.

> 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
>         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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


[jira] Commented: (AXIS2-2811) Assumption that message label and message direction are synonymous

Posted by "Peter Danielsen (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/AXIS2-2811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506748 ] 

Peter Danielsen commented on AXIS2-2811:
----------------------------------------

Amila,

The Interface Message Reference component's "message direction" element information item is set from the element name, rather than an attribute.  See
http://www.w3.org/TR/2007/PR-wsdl20-20070523/#InterfaceMessageReference_Mapping

  "Define the message direction of the element information item to be 'in' 
   if its local name is 'input', and 'out' if its local name is 'output'.

   Note that the messageLabel attribute information item of an interface 
   message reference element information item must be present if the 
   message exchange pattern has more than one placeholder message 
   with {direction} equal to the message direction."

By having both WSDL2 supports the possibility of a future MEP that has more than one message in either direction.

In Woden, a message reference's "direction" is set from the name of the
element: an <input> element has direction = "in", an <output> element has
direction="out".  See org.apache.woden.internal.BaseWSDLReader#parseInterfaceMessageReference

Hope this helps.

Peter

> 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: Amila Chinthaka Suriarachchi
>         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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org