This restriction was added considering the WSRM 1.0 spec where it was not possible to get sync Application responses in a RM sequences. So setting transport In protocol was a must if you need to get response messages.
But due to Message Polling introduced in the new spec it is possible to get reliable response messages without an endpoint in the client side. So i guess we should remove this restriction.
(Message Polling is not implemented yet, but hope to do this in next couple of weeks)
Still I belive we should start the listner if the client sets an Async acksTo endpoint. In this case Sandesha2 will expect the TransportInProtocol to be set. Hope this is ok for the JAX-WS case.
Chamikara
On 8/21/06, Thomas McKiernan <[EMAIL PROTECTED]> wrote:
Hi guys,
Using JAX-WS to invoke Sandesha, I get the following problem for a sync two-way invoke:
org.apache.sandesha2.SandeshaException: cannot start async listener transportInProtocol=null
at org.apache.sandesha2.util.SequenceManager.updateClientSideListnerIfNeeded(SequenceManager.java:355)
at org.apache.sandesha2.util.SequenceManager.setupNewClientSequence(SequenceManager.java:323)
at org.apache.sandesha2.msgprocessors.ApplicationMsgProcessor.processOutMessage(ApplicationMsgProcessor.java:634)
at org.apache.sandesha2.handlers.SandeshaOutHandler.invoke(SandeshaOutHandler.java:131)
at org.apache.axis2.engine.Phase.invoke(Phase.java:380)
at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:528)
at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:638)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:357)
at org.apache.axis2.description.OutInAxisOperationClient.execute(OutInAxisOperation.java:288)
at org.apache.axis2.jaxws.core.controller.AxisInvocationController.invoke(AxisInvocationController.java:146)
at org.apache.axis2.jaxws.client.BaseDispatch.invoke(BaseDispatch.java:123)
at jaxws.tester.JAXInvoker.testSync(JAXInvoker.java:61)
at jaxws.tester.JAXInvoker.main(JAXInvoker.java:133)
Looking at it, the transportInProtocol is not being set and the code is deciding to listen for async acks / cntrl msgs.
The question is whether it is reasonable for Sandesha to expect JAX-WS/Axis2 to have set this field in this situation.
As I understand it, this is only currently done in JAX-WS/Axis2 levels if the client knows that it requires an asyncListener.
But in this case this is not known until it reaches Sandesha - so far as the client is concerned this is just a sync two way call. It is only, I think, because the create sequence flow is required that this is not the case.
Therefore could Sandesha change to use the TransportOut (which I believe is always set) in the case when the TransportInProtocol is not set?
Many thanks,
Thomas
----------------------------------
Thomas McKiernan
WebSphere Messaging Development,
IBM United Kingdom Limited
Internal Phone: 248241
External Phone: +44 (0)1962 818241
Mobile: +44 (0)789 1737497
Email: [EMAIL PROTECTED]
Mail Point 211, IBM, Hursley Park, Winchester, Hampshire, England, SO21 2JN
Caminante, no hay camino
Se hace camino al andar.
("Walker, there is no path; the path is made by walking.") Antonio Machado
