2012/4/23 Daniel Kulp <[email protected]>: > > > This is "proper" behavior as per spec. In a one way, the client just knows > that the message was posted, that's it. As an example, if using JMS, the > client just posts the message to the queue and returns. There is absolutely > no way to get any information about whether the request was able to be > parsed or processed back from the server. > > In 2.6.0, Aki did add a "robust in-only" mode (set the > "org.apache.cxf.oneway.robust" property on the endpoint to true) which would > allow returning faults to the client. This is against spec and transports > like JMS I don't think can handle it (not really sure, Aki?), but but it may > work for you.
A good question. I don't know. Is the JMS endpoint using the fault observer? If it uses the fault observer, it could react to this situation. But I am now confused with what Hervé wants. Should the soap fault be returned or suppressed? I thought he wanted it to be suppressed. If he wanted it to be returned, yes, he could use the robust property. regards, aki > > Dan > > > > On Tuesday, April 17, 2012 03:55:55 PM Hervé BARRAULT wrote: >> Hi, >> I'm trying to use CXF with both WS-Addressing and One Way. >> >> My client send a message (not with CXF) with the following SOAP Header: >> <soapenv:Header> >> <wsa:Action soapenv:mustUnderstand="1"> >> http://docs.oasis-open.org/wsn/bw-2/NotificationConsumer/Notify >> </wsa:Action> >> </soapenv:Header> >> >> In my logs, I had : >> 14:10:31,210 | WARN | ault-workqueue-2 | >> PhaseInterceptorChain | >> org.apache.cxf.common.logging.LogUtils 369 | - >> - | Interceptor for { >> http://example.com/test1}StatusBrokerService#{http://docs.oasis-open.org/w >> sn/brw-2}Notifyhas thrown exception, unwinding now >> org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers: [{ >> http://www.w3.org/2005/08/addressing}Action] are not understood. >> at >> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$Ultimate >> ReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandInterceptor. >> java:225) at >> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$Ultimate >> ReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandInterceptor. >> java:199) at >> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorCha >> in.java:243) at >> org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain.ja >> va:218) at >> org.apache.cxf.interceptor.OneWayProcessorInterceptor$1.run(OneWayProcesso >> rInterceptor.java:105) at >> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$2.run(AutomaticWorkQueueIm >> pl.java:332) at >> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor. >> java:886) at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java >> :908) at java.lang.Thread.run(Thread.java:662) >> >> And there was a classical 202/Accepted for a One Way message (fault not >> returned as it is one way). >> >> >> >> So, I found an interesting topics which says, enable the ws-addressing >> feature (to avoid this fault) : >> I added the feature >> <cxf:features> >> <wsa:addressing/> >> </cxf:features> >> >> Now when i receive a message, an answer is automatically sent (which i >> guess is no more compliant with the One Way): >> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";> >> <soap:Header> >> <MessageID xmlns="http://www.w3.org/2005/08/addressing >> ">urn:uuid:67074ee9-455b-4488-b48d-e2a9b16a7c1b</MessageID> >> <To xmlns="http://www.w3.org/2005/08/addressing";> >> http://www.w3.org/2005/08/addressing/anonymous</To> >> <ReplyTo xmlns="http://www.w3.org/2005/08/addressing";> >> <Address>http://www.w3.org/2005/08/addressing/none</Address> >> </ReplyTo> >> </soap:Header> >> <soap:Body/> >> </soap:Envelope> >> >> I know, i use an old version of CXF : 2.2.12-fuse-00-00 but i have not >> seen a related JIRA (and a post said that 2.4.0 had the same behavior). >> (I am using also the PAYLOAD mode) >> >> I am doing it the right way ? >> Is this behavior normal ? >> >> Thanks for answers >> Regards >> Hervé > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com >
