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.
