On Tuesday, April 24, 2012 11:24:43 AM Hervé BARRAULT wrote: > Hi, > > Sorry if my question was a bit confuse. > > When i had the log it was on the server side [i forgot to precise it] (I > never received the error on the client) which is one of the wanted > behavior. > > I only want the 202 HTTP code with NO content (which is for me the > principle of inOnly but I am perhaps wrong). > I don't know how other client implementations will react if my server > reply some unexpected content (and it adds some useless data on network). > > So for me, the 2.5.2 implementation is the one I expect (not > 2.4.3-fuse-01-02 and previous) . > > 2.5.2 : only 202 HTTP code with no content.<= IMHO : OK
Well, there is the solution: upgrade to 2.5.3 or 2.6.0. For some information about this, see: http://cxf.547215.n5.nabble.com/Adjusting-WS-RM-systests-for-http-202-tt4756114.html and: https://issues.apache.org/jira/browse/CXF-3768 We had a bunch of discussions around the behavior change and decided it really could only go to 2.5.x at the time due to it potentially breaking existing applications. Dan > 2.4.3-fuse-01-02 and previous versions : (soap Header with WS-Addressing > data in any case) <= IMHO : NOT OK > > I am not familiar with WS-Addressing so I could be wrong and the message > used for my testing was given to me. > > If you say me that I should not use soapenv:mustUnderstand="1" with inOnly > (or even WS addressing), I will see if the client can avoid sending it. > But it seems that the behavior is the same without the mustUnderstand. > > For Information, my WSDL contains both inOnly and Request/Response > operation in the same port. > > I hope, it will be less confuse for you. > > The question of robust InOnly is also an interesting question (we are > using a request/response for a wanted robust inOnly) but I think it can > be a dedicated debate. > > Regards > Hervé > > On Mon, Apr 23, 2012 at 11:01 PM, Daniel Kulp <[email protected]> wrote: > > 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/Noti > > > >> fy > > > >> > > > >> </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(MustUnderstandInter > > > >> cep > > > >> tor. java:225) at > > > > org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$Ultim > > > > > >> ate > > > >> ReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandInter > > > >> cep > > > >> 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</Addres > > > >> s> > > > >> > > > >> </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 -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
