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 "Asankha C. Perera (JIRA)" <ji...@apache.org> on 2007/06/30 12:43:04 UTC
[jira] Assigned: (AXIS2-2864) JMS addressing (SOAPBody addressing)
is broken. The new dispatchers can't resolve the required operation
[ https://issues.apache.org/jira/browse/AXIS2-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Asankha C. Perera reassigned AXIS2-2864:
----------------------------------------
Assignee: Davanum Srinivas (was: Asankha C. Perera)
Dims
I don't think this is related to the JMS transport implementation.. could you taka a look at this since its marked a blocker? If its something to do with the transport - please assign back to me.
thanks
asankha
> JMS addressing (SOAPBody addressing) is broken. The new dispatchers can't resolve the required operation
> --------------------------------------------------------------------------------------------------------
>
> Key: AXIS2-2864
> URL: https://issues.apache.org/jira/browse/AXIS2-2864
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: Addressing
> Affects Versions: 1.3
> Environment: Windows XP Tomcat 6.0.10 WebsphereMQ
> Reporter: Mark Badorrek
> Assignee: Davanum Srinivas
> Priority: Blocker
> Fix For: 1.3
>
>
> When sending a JMS message to Axis2 (nightly build) the configured dispatchers can't figure out what operation to use.
> We are not using WS-Addressing. (Although it is enabled in the axis2.xml file)
> Firstly, the InFlow dispatchers are (in order):
> org.apache.axis2.dispatchers.RequestURIBasedDispatcher
> org.apache.axis2.dispatchers.SOAPActionBasedDispatcher
> org.apache.axis2.dispatchers.AddressingBasedDispatcher
> org.apache.axis2.dispatchers.RequestURIOperationDispatcher
> org.apache.axis2.dispatchers.SOAPMessageBodyBasedDispatcher
> All standard stuff except the last (and missing) dispatcher 'HTTPLocationBasedDispatcher' has been removed.
> Of all of these, I expected the last one, 'SOAPMessageBodyBasedDispatcher' to resolve the operation name.
> The JMS message body is as follows:
> ----------------------------
> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
> <SOAP-ENV:Body>
> <m:GetAddressRequestParameter xmlns:m="http://demo">
> <AddressID>String</AddressID>
> </m:GetAddressRequestParameter>
> </SOAP-ENV:Body>
> </SOAP-ENV:Envelope>
> ----------------------------
> So when 'SOAPMessageBodyBasedDispatcher' attempts to work out what to do, it ends up with the magic string 'GetAddressRequestParameter'. It then attempts to resolve this into an operation. (This being the first child element after the 'Body' element)
> Inside 'SOAPMessageBodyBasedDispatcher' we end up in calling 'org.apache.axis2.description.AxisService', method 'getOperation' .
> This method uses our magic variable 'GetAddressRequestParameter' to perform a lookup on the Map 'operationsAliasesMap' to determine what operation to use.
> Unfortunately this lookup fails as the Map 'operationsAliasesMap' only contains the following keys:
> GetAddress
> GetAddressRequest
> urn:GetAddress
> GetAddressResponse
> and importantly does *not* contain our key 'GetAddressRequestParameter'. So no operation for us and our call fails. :-(
> -------------------------------------------------------
> It's quite possible that I'm miss-using the new dispatchers in some way, as I'm not an expert with them. As such I'm not really keen to attempt a patch for fear of breaking other (HTTP) code.
> Please note that the test JMS code was working last week.
--
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