You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Andrei Shakirin <as...@talend.com> on 2012/03/15 13:49:27 UTC
JAX-WS Provider interface and oneWay call
Hi,
Generic CXF service implementing Provider<T> interface interprets all incoming messages as having request-response MEP. Exchange in inbound CXF interceptors chain always returns isOneWay()==false.
It is correct, because normally there is no way to detect from message itself is it belongs to oneWay or request-response MEP.
I have two questions:
1) Is it possible to mark this generic service as oneWay for all messages (and all operations) using annotations or endpoint properties?
2) WS-Addressing interceptor throws fault in case if message is request-response, but ReplyTo contains http://www.w3.org/2005/08/addressing/none value. Is it not too strong? Why warning is not enough? For generic services implementing Provider<T> is not trivial to distinguish between request-response and oneWay messages.
if (!isOneway) {
// if ReplyTo address is none then 202 response status is expected
// However returning a fault is more appropriate for request-response MEP
if (ContextUtils.isNoneAddress(maps.getReplyTo())) {
continueProcessing = false;
...
Regards,
Andrei.
Re: JAX-WS Provider interface and oneWay call
Posted by Aki Yoshida <el...@googlemail.com>.
Hi Dan,
I saw your mail too late. I used MessageUtils.isTrue(obj), which I
remember using it in another occasion.
That would be also okay, I suppose.
regards, aki
2012/3/16 Daniel Kulp <dk...@apache.org>:
>
> Aki,
>
> Just use MessageUtils.getContextualBoolean(....)
>
> and it would handle both cases. :-)
>
> Dan
>
>
> On Friday, March 16, 2012 04:02:42 PM Aki Yoshida wrote:
>> > 2) Small improvement suggestion regarding
>> > "jaxws.provider.interpretNullAsOneway" property: does it make sense to
>> > define property's value as string "true"/"false" instead Boolean
>> > object? It makes configuration via Spring shorter and cleaner:
>> > <jaxws:endpoint
>> > ...
>> > <jaxws:properties>
>> > <entry key="jaxws.provider.interpretNullAsOneway"
>> > value="true" /> </jaxws:properties>
>> > </jaxws:endpoint>
>> >
>> > Instead
>> >
>> > <bean id="BooleanTrue" class="java.lang.Boolean">
>> > <constructor-arg index="0" value="true"/>
>> > </bean>
>> >
>> > <jaxws:endpoint
>> > ...
>> > <jaxws:properties>
>> > <entry key="jaxws.provider.interpretNullAsOneway"
>> > value-ref="BooleanTrue" /> </jaxws:properties>
>> > </jaxws:endpoint>
>> >
>> > What do you think?
>>
>> you are right to point out this inconvenience of using boolean. I'll
>> make it configurable using a simple string value.
>>
>> regards, aki
>>
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
Re: JAX-WS Provider interface and oneWay call
Posted by Daniel Kulp <dk...@apache.org>.
Aki,
Just use MessageUtils.getContextualBoolean(....)
and it would handle both cases. :-)
Dan
On Friday, March 16, 2012 04:02:42 PM Aki Yoshida wrote:
> > 2) Small improvement suggestion regarding
> > "jaxws.provider.interpretNullAsOneway" property: does it make sense to
> > define property's value as string "true"/"false" instead Boolean
> > object? It makes configuration via Spring shorter and cleaner:
> > <jaxws:endpoint
> > ...
> > <jaxws:properties>
> > <entry key="jaxws.provider.interpretNullAsOneway"
> > value="true" /> </jaxws:properties>
> > </jaxws:endpoint>
> >
> > Instead
> >
> > <bean id="BooleanTrue" class="java.lang.Boolean">
> > <constructor-arg index="0" value="true"/>
> > </bean>
> >
> > <jaxws:endpoint
> > ...
> > <jaxws:properties>
> > <entry key="jaxws.provider.interpretNullAsOneway"
> > value-ref="BooleanTrue" /> </jaxws:properties>
> > </jaxws:endpoint>
> >
> > What do you think?
>
> you are right to point out this inconvenience of using boolean. I'll
> make it configurable using a simple string value.
>
> regards, aki
>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: JAX-WS Provider interface and oneWay call
Posted by Aki Yoshida <el...@googlemail.com>.
Hi Andrei,
2012/3/16 Andrei Shakirin <as...@talend.com>:
> Hi Aki,
>
> Thanks for the advice. Interesting for me is of course dynamic case, where service implements Provider<T> interface.
>
> Two points:
> 1) Property "jaxws.provider.interpretNullAsOneway" cannot resolve WS-Addressing problem, because check for "jaxws.provider.interpretNullAsOneway" in JAXWSMethodInvoker happens after invocation and is relevant only for outbound chain. Problem regarding WS-Addressing happens ALREADY on inbound chain, before Provider.invoke() call.
> Precisely saying, there is not reliable method to recognize OneWay and request-response MEPs on inbound chain for dynamic service: invoke() return value is not known yet, there is no service model available and it is not possible to detect it from message.
>
> Therefore I think that Fault in WS-Addressing for none value in ReplyTo for request-response MEP is too strong. Dynamic services cannot really distinguish oneWay from request-response on inbound chain. I will create JIRA entry for it and link it with CXF-3062.
you are right. The check occurs too early. I think we can remove this
check in the request processing and do the verification in the
response processing.
>
> 2) Small improvement suggestion regarding "jaxws.provider.interpretNullAsOneway" property: does it make sense to define property's value as string "true"/"false" instead Boolean object? It makes configuration via Spring shorter and cleaner:
> <jaxws:endpoint
> ...
> <jaxws:properties>
> <entry key="jaxws.provider.interpretNullAsOneway" value="true" />
> </jaxws:properties>
> </jaxws:endpoint>
>
> Instead
>
> <bean id="BooleanTrue" class="java.lang.Boolean">
> <constructor-arg index="0" value="true"/>
> </bean>
>
> <jaxws:endpoint
> ...
> <jaxws:properties>
> <entry key="jaxws.provider.interpretNullAsOneway" value-ref="BooleanTrue" />
> </jaxws:properties>
> </jaxws:endpoint>
>
> What do you think?
you are right to point out this inconvenience of using boolean. I'll
make it configurable using a simple string value.
regards, aki
>
> Regards,
> Andrei.
>
> -----Original Message-----
> From: Aki Yoshida [mailto:elakito@googlemail.com]
> Sent: 15 March 2012 15:29
> To: users@cxf.apache.org
> Subject: Re: JAX-WS Provider<T> interface and oneWay call
>
> Hi Andrei,
> For statically marking the operations to oneway, you can use the javax.jws.Oneway annotation.
> If you want to dynamically switch the mode depending on the return value, you can set the endpoint property jaxws.provider.interpretNullAsOneway to true. In that case, if you are returning a null, the call is treated as a oneway call. For this, see CXF-3926 and a test case org.apache.cxf.systest.provider.InterpretNullAsOnewayProviderTest.
>
> For the addressing question, I think this check relates the required request-response handling check added by CXF-3062. I am not sure if the fault case is covered, though. But in any case, could it be that the above dynamic oneway option may solve your problem?
>
> regards, aki
>
>
> 2012/3/15 Andrei Shakirin <as...@talend.com>:
>> Hi,
>>
>> Generic CXF service implementing Provider<T> interface interprets all incoming messages as having request-response MEP. Exchange in inbound CXF interceptors chain always returns isOneWay()==false.
>> It is correct, because normally there is no way to detect from message itself is it belongs to oneWay or request-response MEP.
>>
>> I have two questions:
>>
>> 1) Is it possible to mark this generic service as oneWay for all messages (and all operations) using annotations or endpoint properties?
>>
>> 2) WS-Addressing interceptor throws fault in case if message is request-response, but ReplyTo contains http://www.w3.org/2005/08/addressing/none value. Is it not too strong? Why warning is not enough? For generic services implementing Provider<T> is not trivial to distinguish between request-response and oneWay messages.
>> if (!isOneway) {
>> // if ReplyTo address is none then 202 response
>> status is expected
>> // However returning a fault is more appropriate
>> for request-response MEP
>> if (ContextUtils.isNoneAddress(maps.getReplyTo()))
>> {
>> continueProcessing = false; ...
>>
>> Regards,
>> Andrei.
RE: JAX-WS Provider interface and oneWay call
Posted by Andrei Shakirin <as...@talend.com>.
Hi Aki,
Thanks for the advice. Interesting for me is of course dynamic case, where service implements Provider<T> interface.
Two points:
1) Property "jaxws.provider.interpretNullAsOneway" cannot resolve WS-Addressing problem, because check for "jaxws.provider.interpretNullAsOneway" in JAXWSMethodInvoker happens after invocation and is relevant only for outbound chain. Problem regarding WS-Addressing happens ALREADY on inbound chain, before Provider.invoke() call.
Precisely saying, there is not reliable method to recognize OneWay and request-response MEPs on inbound chain for dynamic service: invoke() return value is not known yet, there is no service model available and it is not possible to detect it from message.
Therefore I think that Fault in WS-Addressing for none value in ReplyTo for request-response MEP is too strong. Dynamic services cannot really distinguish oneWay from request-response on inbound chain. I will create JIRA entry for it and link it with CXF-3062.
2) Small improvement suggestion regarding "jaxws.provider.interpretNullAsOneway" property: does it make sense to define property's value as string "true"/"false" instead Boolean object? It makes configuration via Spring shorter and cleaner:
<jaxws:endpoint
...
<jaxws:properties>
<entry key="jaxws.provider.interpretNullAsOneway" value="true" />
</jaxws:properties>
</jaxws:endpoint>
Instead
<bean id="BooleanTrue" class="java.lang.Boolean">
<constructor-arg index="0" value="true"/>
</bean>
<jaxws:endpoint
...
<jaxws:properties>
<entry key="jaxws.provider.interpretNullAsOneway" value-ref="BooleanTrue" />
</jaxws:properties>
</jaxws:endpoint>
What do you think?
Regards,
Andrei.
-----Original Message-----
From: Aki Yoshida [mailto:elakito@googlemail.com]
Sent: 15 March 2012 15:29
To: users@cxf.apache.org
Subject: Re: JAX-WS Provider<T> interface and oneWay call
Hi Andrei,
For statically marking the operations to oneway, you can use the javax.jws.Oneway annotation.
If you want to dynamically switch the mode depending on the return value, you can set the endpoint property jaxws.provider.interpretNullAsOneway to true. In that case, if you are returning a null, the call is treated as a oneway call. For this, see CXF-3926 and a test case org.apache.cxf.systest.provider.InterpretNullAsOnewayProviderTest.
For the addressing question, I think this check relates the required request-response handling check added by CXF-3062. I am not sure if the fault case is covered, though. But in any case, could it be that the above dynamic oneway option may solve your problem?
regards, aki
2012/3/15 Andrei Shakirin <as...@talend.com>:
> Hi,
>
> Generic CXF service implementing Provider<T> interface interprets all incoming messages as having request-response MEP. Exchange in inbound CXF interceptors chain always returns isOneWay()==false.
> It is correct, because normally there is no way to detect from message itself is it belongs to oneWay or request-response MEP.
>
> I have two questions:
>
> 1) Is it possible to mark this generic service as oneWay for all messages (and all operations) using annotations or endpoint properties?
>
> 2) WS-Addressing interceptor throws fault in case if message is request-response, but ReplyTo contains http://www.w3.org/2005/08/addressing/none value. Is it not too strong? Why warning is not enough? For generic services implementing Provider<T> is not trivial to distinguish between request-response and oneWay messages.
> if (!isOneway) {
> // if ReplyTo address is none then 202 response
> status is expected
> // However returning a fault is more appropriate
> for request-response MEP
> if (ContextUtils.isNoneAddress(maps.getReplyTo()))
> {
> continueProcessing = false; ...
>
> Regards,
> Andrei.
Re: JAX-WS Provider interface and oneWay call
Posted by Aki Yoshida <el...@googlemail.com>.
Hi Andrei,
For statically marking the operations to oneway, you can use the
javax.jws.Oneway annotation.
If you want to dynamically switch the mode depending on the return
value, you can set the endpoint property
jaxws.provider.interpretNullAsOneway to true. In that case, if you
are returning a null, the call is treated as a oneway call. For this,
see CXF-3926 and a test case
org.apache.cxf.systest.provider.InterpretNullAsOnewayProviderTest.
For the addressing question, I think this check relates the required
request-response handling check added by CXF-3062. I am not sure if
the fault case is covered, though. But in any case, could it be that
the above dynamic oneway option may solve your problem?
regards, aki
2012/3/15 Andrei Shakirin <as...@talend.com>:
> Hi,
>
> Generic CXF service implementing Provider<T> interface interprets all incoming messages as having request-response MEP. Exchange in inbound CXF interceptors chain always returns isOneWay()==false.
> It is correct, because normally there is no way to detect from message itself is it belongs to oneWay or request-response MEP.
>
> I have two questions:
>
> 1) Is it possible to mark this generic service as oneWay for all messages (and all operations) using annotations or endpoint properties?
>
> 2) WS-Addressing interceptor throws fault in case if message is request-response, but ReplyTo contains http://www.w3.org/2005/08/addressing/none value. Is it not too strong? Why warning is not enough? For generic services implementing Provider<T> is not trivial to distinguish between request-response and oneWay messages.
> if (!isOneway) {
> // if ReplyTo address is none then 202 response status is expected
> // However returning a fault is more appropriate for request-response MEP
> if (ContextUtils.isNoneAddress(maps.getReplyTo())) {
> continueProcessing = false;
> ...
>
> Regards,
> Andrei.