On Nov 7, 2012, at 9:36 PM, viola lu <[email protected]> wrote: > https://issues.apache.org/jira/browse/CXF-4611 > > Can somebody help review it? I already build it against cxf trunk, no > failure. Thanks in advance!
I just committed it. I kept the changes to the tests as they were fine. I changed the stuff in the JAXWSMethodInvoker to use the MessageUtils.getContextualBoolean call directly which can return the true/false that we want as the default if the property isn't set. A little cleaner. HOWEVER, this exposed another pretty bug. With the change, one of the jms system tests then hung. When a provider uses a continuation to suspend the request, one common way to handle it is to return a null. This caused the exchange to flip to a one-way and no response ever sent. I had to update the if statement to also check to make sure the interceptor chain wasn't suspended. Dan > > On Thu, Nov 1, 2012 at 2:04 PM, viola lu <[email protected]> wrote: > >> Okay, i can open a jira and provide a fix if no objection. >> >> >> On Thu, Nov 1, 2012 at 6:58 AM, Aki Yoshida <[email protected]> wrote: >> >>> Okay. >>> In that case, maybe we could change the default to true in trunk now >>> and run the TCK tests with that code to see if there is some issue. >>> If there is no issue, we can put the change in 2.7.1. In this way, we >>> won't forget about it. If this change is to be made, I think the >>> earlier, the better. >>> >>> regards, aki >>> >>> 2012/10/31 Glen Mazza <[email protected]>: >>>> Unsure of how much a spec issue this actually is, but I would say >>> adherence >>>> to the spec (whether or not trapped by the TCK) is more important than >>>> backwards compatibility, to avoid competitors claiming that we're not >>> really >>>> spec-compliant. Perhaps this change can be made in CXF 2.8.0. >>>> >>>> Glen >>>> >>>> >>>> On 10/30/2012 10:24 PM, viola lu wrote: >>>>> >>>>> But from spec, it should be. And if i run the application on axis2, it >>>>> returns 202 http code directly. >>>>> >>>>> On Fri, Oct 26, 2012 at 4:48 PM, Aki Yoshida <[email protected]> >>> wrote: >>>>> >>>>>> 2012/10/26 viola lu <[email protected]>: >>>>>>> >>>>>>> I saw changes in jira https://issues.apache.org/jira/browse/CXF-4182 >>> , >>>>>> >>>>>> and i >>>>>>> >>>>>>> tried this property, it worked. But from >>>>>>> Jaxws spec 5.1.1 Invocation >>>>>>> A Provider based service instance’s invoke method is called for each >>>>>>> message received for the service. >>>>>>> When an invoke method returns null, it is considered that no response >>>>>> >>>>>> needs >>>>>>> >>>>>>> to be sent by service >>>>>>> >>>>>>> i think it's better to automatically switch to oneway and return 202 >>> as >>>>>> >>>>>> Aki >>>>>>> >>>>>>> Yoshida mentioned . I can update JAXWSMethodInvoker to make this >>> happen. >>>>>>> Your comments? >>>>>> >>>>>> Hi Viola, >>>>>> >>>>>> We could have chosen the default value to be true and made this >>>>>> behavior automatically enabled. But we were concerned about changing >>>>>> the existing behavior and hence, opted for introducing an endpoint >>>>>> option to explicitly enable this behavior. I don't know if there is >>>>>> really a need to change its default value now unless Jaxws TCK or >>>>>> something really requires this change. >>>>>> >>>>>> Regards, aki >>>>>> >>>>>> >>>>>>> On Fri, Oct 26, 2012 at 10:06 AM, viola lu <[email protected]> >>> wrote: >>>>>>> >>>>>>>> i am using cxf 2.6.2, does it support >>>>>> >>>>>> jaxws.provider.interpretNullAsOneway >>>>>>>> >>>>>>>> property? >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Oct 25, 2012 at 9:20 PM, Andrei Shakirin < >>> [email protected] >>>>>>> >>>>>>> wrote: >>>>>>>>> >>>>>>>>> In earlier CXF versions is possible to specify it explicitly via >>>>>> >>>>>> endpoint >>>>>>>>> >>>>>>>>> property "jaxws.provider.interpretNullAsOneway": >>>>>>>>> >>>>>>>>> <bean id="BooleanTrue" class="java.lang.Boolean"> >>>>>>>>> <constructor-arg index="0" value="true"/> >>>>>>>>> </bean> >>>>>>>>> >>>>>>>>> <jaxws:endpoint xmlns:customer=" >>>>>>>>> http://customerservice.example.com/"; >>>>>>>>> id="CustomerServiceHTTP" address=" >>>>>>>>> http://xxx.yyy.com/service/customservice"; >>>>>>>>> >>>>>>>>> >>> implementor="com.example.customerservice.server.CustomerServiceImpl"> >>>>>>>>> <jaxws:properties> >>>>>>>>> <entry >>>>>>>>> key="jaxws.provider.interpretNullAsOneway" value-ref="BooleanTrue" >>> /> >>>>>>>>> </jaxws:properties> >>>>>>>>> </jaxws:endpoint> >>>>>>>>> >>>>>>>>> Andrei. >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Aki Yoshida [mailto:[email protected]] >>>>>>>>> Sent: Donnerstag, 25. Oktober 2012 14:54 >>>>>>>>> To: [email protected] >>>>>>>>> Cc: [email protected] >>>>>>>>> Subject: Re: Get a null pointer if provider returns null response >>> in >>>>>>>>> payload message mode. >>>>>>>>> >>>>>>>>> hi, >>>>>>>>> Which version of CXF are you using? >>>>>>>>> I thought it should automatically switch to a pseudo oneway mode >>> and >>>>>>>>> return an empty http 202 response and this should be handled witout >>>>>>>>> throwing an NPE. >>>>>>>>> regards, aki >>>>>>>>> p.s. moved this to users@cxf >>>>>>>>> >>>>>>>>> >>>>>>>>> 2012/10/25 viola lu <[email protected]>: >>>>>>>>>> >>>>>>>>>> Hi, Dev: >>>>>>>>>> >>>>>>>>>> I wrote a sample DOMSource payload provider as below: >>>>>>>>>> >>>>>>>>>> @WebServiceProvider() >>>>>>>>>> public class GreeterDOMSourcePayloadProvider implements >>>>>>>>>> Provider<DOMSource> { >>>>>>>>>> >>>>>>>>>> public GreeterDOMSourcePayloadProvider() { >>>>>>>>>> //Complete >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> public DOMSource invoke(DOMSource request) { >>>>>>>>>> DOMSource response = new DOMSource(); >>>>>>>>>> return null; >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> and run client against it: >>>>>>>>>> >>>>>>>>>> QName serviceName3 = new >>>>>>>>>> QName("http://apache.org/hello_world_soap_http";, >>>>>>>>>> "SOAPService3"); >>>>>>>>>> QName portName3 = new >>>>>>>>>> QName("http://apache.org/hello_world_soap_http";, >>>>>>>>>> "SoapPort3"); >>>>>>>>>> >>>>>>>>>> SOAPService3 service3 = new SOAPService3(wsdlURL, >>>>>> >>>>>> serviceName3); >>>>>>>>>> >>>>>>>>>> InputStream is3 = >>>>>>>>>> Client.class.getResourceAsStream("GreetMeDocLiteralReq3.xml"); >>>>>>>>>> if (is3 == null) { >>>>>>>>>> System.err.println("Failed to create input stream >>> from >>>>>> >>>>>> file >>>>>>>>> >>>>>>>>> " >>>>>>>>>> >>>>>>>>>> + "GreetMeDocLiteralReq3.xml, >>> please >>>>>>>>> >>>>>>>>> check"); >>>>>>>>>> >>>>>>>>>> System.exit(-1); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> SOAPMessage soapReq3 = >>>>>>>>>> MessageFactory.newInstance().createMessage(null, is3); >>>>>>>>>> DOMSource domReqPayload = new >>>>>>>>>> DOMSource(soapReq3.getSOAPBody().extractContentAsDocument()); >>>>>>>>>> >>>>>>>>>> Dispatch<DOMSource> dispDOMSrcPayload = >>>>>>>>>> service3.createDispatch(portName3, >>>>>>>>>> >>>>>>>>>> DOMSource.class, Mode.PAYLOAD); >>>>>>>>>> System.out.println("Invoking server through Dispatch >>>>>> >>>>>> interface >>>>>>>>>> >>>>>>>>>> using DOMSource in PAYLOAD Mode"); >>>>>>>>>> DOMSource domRespPayload = >>>>>>>>>> dispDOMSrcPayload.invoke(domReqPayload); >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> but got an null pointer exception in BareOutputInterceptor. >>>>>>>>>> >>>>>>>>>> CXF doesn't support null return response in payload mode? I tried >>> it >>>>>>>>>> in message mode, it returns an empty >>> <soap-env:body></soap-env:body>, >>>>>>>>>> but not in payload mode. >>>>>>>>>> >>>>>>>>>> I think it should keep same in both mode. Is this a defect of cxf? >>>>>>>>>> >>>>>>>>>> You can reproduce it by reusing cxf sample : >>> jaxws_dispatch_provider >>>>>>>>>> >>>>>>>>>> Appreciate your comments. >>>>>>>>>> -- >>>>>>>>>> viola >>>>>>>>>> >>>>>>>>>> Apache Geronimo >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> viola >>>>>>>> >>>>>>>> Apache Geronimo >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> viola >>>>>>> >>>>>>> Apache Geronimo >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Glen Mazza >>>> Talend Community Coders - coders.talend.com >>>> blog: www.jroller.com/gmazza >>>> >>> >> >> >> >> -- >> viola >> >> Apache Geronimo >> >> > > > -- > viola > > Apache Geronimo -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
