You are viewing a plain text version of this content. The canonical link for it is here.

Posted to fx-dev@ws.apache.org by Thomas McKiernan <MC...@uk.ibm.com> on 2006/08/21 17:30:22 UTC

use transportOutProtocol to setup async listeners

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: MCKIERNA@uk.ibm.com

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

Re: use transportOutProtocol to setup async listeners

Posted by Chamikara Jayalath <ch...@gmail.com>.

Hi Thomas,



>
> > Ok, so as I understand it, this currently works today i.e. without
> > polling, provided that the transportIn etc is setup.
> > I agree that Sandesha needs to setup an async listener for an
> > addressable acksTo. However, is it necessarily right that the client or
> > jaxWS layer should know that, by setting an acksTo, it also has to set up a
> > transportInProtocol, in order for this async listener to be set up? It seems
> > to me that some implementation detail of sandesha is that an async listener
> > is used to receive response messages during an addressable synchronous flow.
> > It seems therefore that it would be good to shield the jaxWS layer from this
> > implementationd detail. What would be the effect of using transportOut
> > details to setup the transportIn in the case of one not having been set?
> >
>
> OK. This seems to be a valid requirement. I'll do this change. Thaks for
> pointing it out
>


Done.

Chamikara

Re: use transportOutProtocol to setup async listeners

Posted by Chamikara Jayalath <ch...@gmail.com>.

Hi Jaliya,

On 8/22/06, Jaliya Ekanayake <jn...@gmail.com> wrote:
>
>  Hi All,
>
> Few thoughts inline.
>
> -Jaliya
>
> ----- Original Message -----
> *From:* Chamikara Jayalath <ch...@gmail.com>
> *To:* Thomas McKiernan <MC...@uk.ibm.com>
> *Cc:* sandesha-dev@ws.apache.org
> *Sent:* Tuesday, August 22, 2006 6:53 AM
> *Subject:* Re: use transportOutProtocol to setup async listeners
>
> Hi Thomas,
>
> See my comments below.
>
> On 8/22/06, Thomas McKiernan <MC...@uk.ibm.com> wrote:
>
> >
> > Hi Chamikara,
> > Thanks for your response - I've asked some questions/made some comments
> > in blue.
> >
> >
> > This restriction was added considering the WSRM 1.0 spec where it was
> > not possible to get sync Application responses in a RM sequences.
> >
>
>  Ok, I think I understand. Therefore when polling is introduced, is it
> > correct to say that sync 2-way with an anonymous acksTo will work and an
> > async listener/transportIn etc will not be required for that particular
> > flow?
> >
>
>
> yes
>
>
>  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.
> >
>
>
>
> > Ok, so as I understand it, this currently works today i.e. without
> > polling, provided that the transportIn etc is setup.
> > I agree that Sandesha needs to setup an async listener for an
> > addressable acksTo. However, is it necessarily right that the client or
> > jaxWS layer should know that, by setting an acksTo, it also has to set up a
> > transportInProtocol, in order for this async listener to be set up? It seems
> > to me that some implementation detail of sandesha is that an async listener
> > is used to receive response messages during an addressable synchronous flow.
> > It seems therefore that it would be good to shield the jaxWS layer from this
> > implementationd detail. What would be the effect of using transportOut
> > details to setup the transportIn in the case of one not having been set?
> >
>
> OK. This seems to be a valid requirement. I'll do this change. Thaks for
> pointing it out
>
> This is ok but we need to make sure that we have a very clear way to get
> things done. So jaxWS does not need different transports by any chance?
>
>
What Thomas is talking abt is the case where the user has not set any
incoming transport. If he want he can set the transportInProtocol which will
be picked by Sandesha (and Axis2).

Chamikara





>
> >
> >
> >
> > ----------------------------------
> > Thomas McKiernan
> >
> > WebSphere Messaging Development,
> > IBM United Kingdom Limited
> >
> > Internal Phone: 248241
> > External Phone: +44 (0)1962 818241
> > Mobile: +44 (0)789 1737497
> > Email: MCKIERNA@uk.ibm.com
> >
> > 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
> >
> >
> >   *"Chamikara Jayalath" <ch...@gmail.com>*
> >
> > 22/08/2006 06:23
> >    To
> > Thomas McKiernan/UK/IBM@IBMGB  cc
> > sandesha-dev@ws.apache.org  Subject
> > Re: use transportOutProtocol to setup async listeners
> >
> >
> >
> >
> >
> >
> > Hi Thomas,
> >
> > 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* <*MCKIERNA@uk.ibm.com *<MC...@uk.ibm.com>>
> > 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: *MCKIERNA@uk.ibm.com* <MC...@uk.ibm.com>
> >
> > 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
> >
> >
>

Re: use transportOutProtocol to setup async listeners

Posted by Chamikara Jayalath <ch...@gmail.com>.

Hi Jaliya,

On 8/22/06, Jaliya Ekanayake <jn...@gmail.com> wrote:
>
>  Hi All,
>
> Few thoughts inline.
>
> -Jaliya
>
> ----- Original Message -----
> *From:* Chamikara Jayalath <ch...@gmail.com>
> *To:* Thomas McKiernan <MC...@uk.ibm.com>
> *Cc:* sandesha-dev@ws.apache.org
> *Sent:* Tuesday, August 22, 2006 6:53 AM
> *Subject:* Re: use transportOutProtocol to setup async listeners
>
> Hi Thomas,
>
> See my comments below.
>
> On 8/22/06, Thomas McKiernan <MC...@uk.ibm.com> wrote:
>
> >
> > Hi Chamikara,
> > Thanks for your response - I've asked some questions/made some comments
> > in blue.
> >
> >
> > This restriction was added considering the WSRM 1.0 spec where it was
> > not possible to get sync Application responses in a RM sequences.
> >
>
>  Ok, I think I understand. Therefore when polling is introduced, is it
> > correct to say that sync 2-way with an anonymous acksTo will work and an
> > async listener/transportIn etc will not be required for that particular
> > flow?
> >
>
>
> yes
>
>
>  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.
> >
>
>
>
> > Ok, so as I understand it, this currently works today i.e. without
> > polling, provided that the transportIn etc is setup.
> > I agree that Sandesha needs to setup an async listener for an
> > addressable acksTo. However, is it necessarily right that the client or
> > jaxWS layer should know that, by setting an acksTo, it also has to set up a
> > transportInProtocol, in order for this async listener to be set up? It seems
> > to me that some implementation detail of sandesha is that an async listener
> > is used to receive response messages during an addressable synchronous flow.
> > It seems therefore that it would be good to shield the jaxWS layer from this
> > implementationd detail. What would be the effect of using transportOut
> > details to setup the transportIn in the case of one not having been set?
> >
>
> OK. This seems to be a valid requirement. I'll do this change. Thaks for
> pointing it out
>
> This is ok but we need to make sure that we have a very clear way to get
> things done. So jaxWS does not need different transports by any chance?
>
>
What Thomas is talking abt is the case where the user has not set any
incoming transport. If he want he can set the transportInProtocol which will
be picked by Sandesha (and Axis2).

Chamikara





>
> >
> >
> >
> > ----------------------------------
> > Thomas McKiernan
> >
> > WebSphere Messaging Development,
> > IBM United Kingdom Limited
> >
> > Internal Phone: 248241
> > External Phone: +44 (0)1962 818241
> > Mobile: +44 (0)789 1737497
> > Email: MCKIERNA@uk.ibm.com
> >
> > 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
> >
> >
> >   *"Chamikara Jayalath" <ch...@gmail.com>*
> >
> > 22/08/2006 06:23
> >    To
> > Thomas McKiernan/UK/IBM@IBMGB  cc
> > sandesha-dev@ws.apache.org  Subject
> > Re: use transportOutProtocol to setup async listeners
> >
> >
> >
> >
> >
> >
> > Hi Thomas,
> >
> > 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* <*MCKIERNA@uk.ibm.com *<MC...@uk.ibm.com>>
> > 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: *MCKIERNA@uk.ibm.com* <MC...@uk.ibm.com>
> >
> > 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
> >
> >
>

Re: use transportOutProtocol to setup async listeners

Posted by Jaliya Ekanayake <jn...@gmail.com>.

Hi All,

Few thoughts inline.

-Jaliya
----- Original Message -----
From: Chamikara Jayalath
To: Thomas McKiernan
Cc: sandesha-dev@ws.apache.org
Sent: Tuesday, August 22, 2006 6:53 AM
Subject: Re: use transportOutProtocol to setup async listeners

Hi Thomas,

See my comments below.

On 8/22/06, Thomas McKiernan <MC...@uk.ibm.com> wrote:

Hi Chamikara,
Thanks for your response - I've asked some questions/made some comments in blue.

This restriction was added considering the WSRM 1.0 spec where it was not possible to get sync Application responses in a RM sequences.

Ok, I think I understand. Therefore when polling is introduced, is it correct to say that sync 2-way with an anonymous acksTo will work and an async listener/transportIn etc will not be required for that particular flow?

yes

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.

Ok, so as I understand it, this currently works today i.e. without polling, provided that the transportIn etc is setup.
I agree that Sandesha needs to setup an async listener for an addressable acksTo. However, is it necessarily right that the client or jaxWS layer should know that, by setting an acksTo, it also has to set up a transportInProtocol, in order for this async listener to be set up? It seems to me that some implementation detail of sandesha is that an async listener is used to receive response messages during an addressable synchronous flow. It seems therefore that it would be good to shield the jaxWS layer from this implementationd detail. What would be the effect of using transportOut details to setup the transportIn in the case of one not having been set?

OK. This seems to be a valid requirement. I'll do this change. Thaks for pointing it out

This is ok but we need to make sure that we have a very clear way to get things done. So jaxWS does not need different transports by any chance?

Chamikara

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: MCKIERNA@uk.ibm.com

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

"Chamikara Jayalath" <ch...@gmail.com>
22/08/2006 06:23
To Thomas McKiernan/UK/IBM@IBMGB
cc sandesha-dev@ws.apache.org
Subject Re: use transportOutProtocol to setup async listeners

Hi Thomas,

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 <MCKIERNA@uk.ibm.com > 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: MCKIERNA@uk.ibm.com

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

Re: use transportOutProtocol to setup async listeners

Posted by Jaliya Ekanayake <jn...@gmail.com>.

Hi All,

Few thoughts inline.

Hi Thomas,

See my comments below.

On 8/22/06, Thomas McKiernan <MC...@uk.ibm.com> wrote:

Hi Chamikara,
Thanks for your response - I've asked some questions/made some comments in blue.

This restriction was added considering the WSRM 1.0 spec where it was not possible to get sync Application responses in a RM sequences.

yes

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.

OK. This seems to be a valid requirement. I'll do this change. Thaks for pointing it out

This is ok but we need to make sure that we have a very clear way to get things done. So jaxWS does not need different transports by any chance?

Chamikara

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: MCKIERNA@uk.ibm.com

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

"Chamikara Jayalath" <ch...@gmail.com>
22/08/2006 06:23
To Thomas McKiernan/UK/IBM@IBMGB
cc sandesha-dev@ws.apache.org
Subject Re: use transportOutProtocol to setup async listeners

Hi Thomas,

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 <MCKIERNA@uk.ibm.com > wrote:

Hi guys,
Using JAX-WS to invoke Sandesha, I get the following problem for a sync two-way invoke:

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: MCKIERNA@uk.ibm.com

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

Re: use transportOutProtocol to setup async listeners

Posted by Chamikara Jayalath <ch...@gmail.com>.

Hi Thomas,



>
> > Ok, so as I understand it, this currently works today i.e. without
> > polling, provided that the transportIn etc is setup.
> > I agree that Sandesha needs to setup an async listener for an
> > addressable acksTo. However, is it necessarily right that the client or
> > jaxWS layer should know that, by setting an acksTo, it also has to set up a
> > transportInProtocol, in order for this async listener to be set up? It seems
> > to me that some implementation detail of sandesha is that an async listener
> > is used to receive response messages during an addressable synchronous flow.
> > It seems therefore that it would be good to shield the jaxWS layer from this
> > implementationd detail. What would be the effect of using transportOut
> > details to setup the transportIn in the case of one not having been set?
> >
>
> OK. This seems to be a valid requirement. I'll do this change. Thaks for
> pointing it out
>


Done.

Chamikara

Re: use transportOutProtocol to setup async listeners

Posted by Chamikara Jayalath <ch...@gmail.com>.

Hi Thomas,

See my comments below.

On 8/22/06, Thomas McKiernan <MC...@uk.ibm.com> wrote:
>
>
> Hi Chamikara,
> Thanks for your response - I've asked some questions/made some comments in
> blue.
>
>
> This restriction was added considering the WSRM 1.0 spec where it was not
> possible to get sync Application responses in a RM sequences.
>

Ok, I think I understand. Therefore when polling is introduced, is it
> correct to say that sync 2-way with an anonymous acksTo will work and an
> async listener/transportIn etc will not be required for that particular
> flow?
>


yes


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.
>



> Ok, so as I understand it, this currently works today i.e. without
> polling, provided that the transportIn etc is setup.
> I agree that Sandesha needs to setup an async listener for an addressable
> acksTo. However, is it necessarily right that the client or jaxWS layer
> should know that, by setting an acksTo, it also has to set up a
> transportInProtocol, in order for this async listener to be set up? It seems
> to me that some implementation detail of sandesha is that an async listener
> is used to receive response messages during an addressable synchronous flow.
> It seems therefore that it would be good to shield the jaxWS layer from this
> implementationd detail. What would be the effect of using transportOut
> details to setup the transportIn in the case of one not having been set?
>

OK. This seems to be a valid requirement. I'll do this change. Thaks for
pointing it out


Chamikara


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: MCKIERNA@uk.ibm.com
>
> 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
>
>
>  *"Chamikara Jayalath" <ch...@gmail.com>*
>
> 22/08/2006 06:23
>   To
> Thomas McKiernan/UK/IBM@IBMGB  cc
> sandesha-dev@ws.apache.org  Subject
> Re: use transportOutProtocol to setup async listeners
>
>
>
>
>
>
> Hi Thomas,
>
> 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* <*M...@uk.ibm.com>>
> 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: *MCKIERNA@uk.ibm.com* <MC...@uk.ibm.com>
>
> 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
>
>

Re: use transportOutProtocol to setup async listeners

Posted by Chamikara Jayalath <ch...@gmail.com>.

Hi Thomas,

See my comments below.

On 8/22/06, Thomas McKiernan <MC...@uk.ibm.com> wrote:
>
>
> Hi Chamikara,
> Thanks for your response - I've asked some questions/made some comments in
> blue.
>
>
> This restriction was added considering the WSRM 1.0 spec where it was not
> possible to get sync Application responses in a RM sequences.
>

Ok, I think I understand. Therefore when polling is introduced, is it
> correct to say that sync 2-way with an anonymous acksTo will work and an
> async listener/transportIn etc will not be required for that particular
> flow?
>


yes


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.
>



> Ok, so as I understand it, this currently works today i.e. without
> polling, provided that the transportIn etc is setup.
> I agree that Sandesha needs to setup an async listener for an addressable
> acksTo. However, is it necessarily right that the client or jaxWS layer
> should know that, by setting an acksTo, it also has to set up a
> transportInProtocol, in order for this async listener to be set up? It seems
> to me that some implementation detail of sandesha is that an async listener
> is used to receive response messages during an addressable synchronous flow.
> It seems therefore that it would be good to shield the jaxWS layer from this
> implementationd detail. What would be the effect of using transportOut
> details to setup the transportIn in the case of one not having been set?
>

OK. This seems to be a valid requirement. I'll do this change. Thaks for
pointing it out


Chamikara


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: MCKIERNA@uk.ibm.com
>
> 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
>
>
>  *"Chamikara Jayalath" <ch...@gmail.com>*
>
> 22/08/2006 06:23
>   To
> Thomas McKiernan/UK/IBM@IBMGB  cc
> sandesha-dev@ws.apache.org  Subject
> Re: use transportOutProtocol to setup async listeners
>
>
>
>
>
>
> Hi Thomas,
>
> 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* <*M...@uk.ibm.com>>
> 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: *MCKIERNA@uk.ibm.com* <MC...@uk.ibm.com>
>
> 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
>
>

[Sandeshaya2/C] Build failure

Posted by Samisa Abeysinghe <sa...@gmail.com>.

I took a fresh snv checkout and the build fails :(

cc1: warnings being treated as errors
sandesha2_utils.c: In function 'sandesha2_utils_start_polling_mgr':
sandesha2_utils.c:430: warning: assignment makes pointer from integer
without a cast
sandesha2_utils.c: In function 'sandesha2_utils_create_new_related_msg_ctx':
sandesha2_utils.c:745: warning: passing argument 4 of
'new_msg->ops->set_property' makes pointer from integer without a cast
sandesha2_utils.c:751: warning: passing argument 4 of
'new_msg->ops->set_property' makes pointer from integer without a cast
sandesha2_utils.c:756: warning: passing argument 4 of
'new_msg->ops->set_property' makes pointer from integer without a cast
sandesha2_utils.c:761: warning: passing argument 4 of
'new_msg->ops->set_property' makes pointer from integer without a cast
make[2]: *** [sandesha2_utils.lo] Error 1


Samisa...


---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org

[Sandeshaya2/C] Build failure

Posted by Samisa Abeysinghe <sa...@gmail.com>.

I took a fresh snv checkout and the build fails :(

cc1: warnings being treated as errors
sandesha2_utils.c: In function 'sandesha2_utils_start_polling_mgr':
sandesha2_utils.c:430: warning: assignment makes pointer from integer
without a cast
sandesha2_utils.c: In function 'sandesha2_utils_create_new_related_msg_ctx':
sandesha2_utils.c:745: warning: passing argument 4 of
'new_msg->ops->set_property' makes pointer from integer without a cast
sandesha2_utils.c:751: warning: passing argument 4 of
'new_msg->ops->set_property' makes pointer from integer without a cast
sandesha2_utils.c:756: warning: passing argument 4 of
'new_msg->ops->set_property' makes pointer from integer without a cast
sandesha2_utils.c:761: warning: passing argument 4 of
'new_msg->ops->set_property' makes pointer from integer without a cast
make[2]: *** [sandesha2_utils.lo] Error 1


Samisa...


---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org

Re: use transportOutProtocol to setup async listeners

Posted by Thomas McKiernan <MC...@uk.ibm.com>.

Hi Chamikara,
Thanks for your response - I've asked some questions/made some comments in
blue.

This restriction was added considering the WSRM 1.0 spec where it was not
possible to get sync Application responses in a RM sequences.
Ok, I think I understand. Therefore when polling is introduced, is it
correct to say that sync 2-way with an anonymous acksTo will work and an
async listener/transportIn etc will not be required for that particular
flow?

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.
Ok, so as I understand it, this currently works today i.e. without
polling, provided that the transportIn etc is setup.
I agree that Sandesha needs to setup an async listener for an addressable
acksTo. However, is it necessarily right that the client or jaxWS layer
should know that, by setting an acksTo, it also has to set up a
transportInProtocol, in order for this async listener to be set up? It
seems to me that some implementation detail of sandesha is that an async
listener is used to receive response messages during an addressable
synchronous flow. It seems therefore that it would be good to shield the
jaxWS layer from this implementationd detail. What would be the effect of
using transportOut details to setup the transportIn in the case of one not
having been 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: MCKIERNA@uk.ibm.com

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

"Chamikara Jayalath" <ch...@gmail.com>
22/08/2006 06:23

To
Thomas McKiernan/UK/IBM@IBMGB
cc
sandesha-dev@ws.apache.org
Subject
Re: use transportOutProtocol to setup async listeners

Hi Thomas,

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 <MC...@uk.ibm.com> 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?