On Monday, April 23, 2012 10:50:05 PM Aki Yoshida wrote: > 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.
Well, I assume there is a fault observer on the server side, the issue is on the client side. For a one way, the client would send the message to the JMS queue and then continue on it's merry way. There wouldn't be anything setup to listen for a fault. Honestly, I'm not really sure what would be a proper thing to do in this case. If the client treats the "robust oneway" calls as a two way and sets up a listener, then the server would have to send back a response of some sort. I guess a "jms fake 202" could be sent or something. But it's really getting into proprietary things at this point. I guess I should go back to the SOAP/JMS spec and see if it addresses the WSDL 2 robust cases at all. > 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. I thought it WAS suppressed (and only the 202 is heading back) but he wanted the mustunderstand fault to go back to the client. I could likely be confused as well. Dan > > 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.or > >> g/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$Ultim > >> ate > >> ReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandIntercep > >> tor. java:225) at > >> org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$Ultim > >> ate > >> ReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandIntercep > >> tor. java:199) at > >> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptor > >> Cha in.java:243) at > >> org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain > >> .ja va:218) at > >> org.apache.cxf.interceptor.OneWayProcessorInterceptor$1.run(OneWayProce > >> sso rInterceptor.java:105) at > >> org.apache.cxf.workqueue.AutomaticWorkQueueImpl$2.run(AutomaticWorkQueu > >> eIm pl.java:332) at > >> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecut > >> or. java:886) at > >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.j > >> ava>> > >> :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 -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
