Hi Andrei, 2012/3/16 Andrei Shakirin <[email protected]>: > 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:[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.
