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:[email protected]]
Sent: 15 March 2012 15:29
To: [email protected]
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 <[email protected]>:
> 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.
