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 "Mark Badorrek (JIRA)" <ji...@apache.org> on 2007/06/27 04:05:25 UTC
[jira] Created: (AXIS2-2864) JMS addressing (SOAPBody addressing)
is broken. The new dispatchers can't resolve the required operation
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
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
[jira] Updated: (AXIS2-2864) JMS addressing (SOAPBody addressing)
is broken. The new dispatchers can't resolve the required operation
Posted by "Davanum Srinivas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Davanum Srinivas updated AXIS2-2864:
------------------------------------
Assignee: Asankha C. Perera
> 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: Asankha C. Perera
> 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
[jira] Resolved: (AXIS2-2864) JMS addressing (SOAPBody addressing)
is broken. The new dispatchers can't resolve the required operation
Posted by "Deepal Jayasinghe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Deepal Jayasinghe resolved AXIS2-2864.
--------------------------------------
Resolution: Fixed
Fix Version/s: (was: 1.3)
nightly
I tested the body based dispatching and it worked when we send the valid request , I send the request w.o soapaction and Axis2 was able to dispatch without having any problem.
I will marked this issues as resolve , please tested and confirm . If you still have the issue please re-open the issue with a test case.
> 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: Deepal Jayasinghe
> Priority: Blocker
> Fix For: nightly
>
>
> 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
[jira] Updated: (AXIS2-2864) JMS addressing (SOAPBody addressing)
is broken. The new dispatchers can't resolve the required operation
Posted by "Davanum Srinivas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Davanum Srinivas updated AXIS2-2864:
------------------------------------
Assignee: Deepal Jayasinghe (was: Davanum Srinivas)
> 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: Deepal Jayasinghe
> 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
[jira] Assigned: (AXIS2-2864) JMS addressing (SOAPBody addressing)
is broken. The new dispatchers can't resolve the required operation
Posted by "Asankha C. Perera (JIRA)" <ji...@apache.org>.
[ 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
[jira] Commented: (AXIS2-2864) JMS addressing (SOAPBody addressing)
is broken. The new dispatchers can't resolve the required operation
Posted by "Mark Badorrek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509730 ]
Mark Badorrek commented on AXIS2-2864:
--------------------------------------
Hi Deepal,
I re-tested this as well with the nightly build and everything is indeed OK. I probably had an issue with using client-generated code from an earlier nightly build against the current server nightly build.
This is the best type of resolution - nothing to do. :-)
Cheers,
Mark B
> 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: Deepal Jayasinghe
> Priority: Blocker
> Fix For: nightly
>
>
> 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