One last thing: This test started failing when I updated from one version of CXF 3.1.x to another a long time ago. I am now migrating to CXF 3.3.x and must resolve this outstanding issue. I see that this check was added by https://issues.apache.org/jira/browse/CXF-7653 and I can only deduce that this started failing with this change.
Thank you! Gary On Fri, Mar 22, 2019 at 9:14 AM Gary Gregory <[email protected]> wrote: > In the debugger, for "boi.getOutput().getMessageParts()" I get one part: > > boi.getOutput().getMessageParts() > (java.util.ArrayList<E>) [[MessagePartInfo > name={TestWebServiceNS}parameters, > ConcreteName={TestWebServiceNS}echoVoidResponse] > > boi.getOutput().getMessageParts().get(0) > (org.apache.cxf.service.model.MessagePartInfo) [MessagePartInfo > name={TestWebServiceNS}parameters, > ConcreteName={TestWebServiceNS}echoVoidResponse > > Thoughts? > > Gary > > On Fri, Mar 22, 2019 at 9:11 AM Gary Gregory <[email protected]> > wrote: > >> Hi Andriy, >> >> Thank you for your prompt reply :-) >> >> I am not convinced just yet. To confirm we both see this the same way now: >> - If resList is null, then there is no response defined in the schema? >> (which matches my app's "echo void" test) >> >> My echo void test looks like this; I believe this was generated by some >> CXF tooling: >> >> package testwebservicens; >> >> import javax.xml.bind.annotation.XmlAccessType; >> import javax.xml.bind.annotation.XmlAccessorType; >> import javax.xml.bind.annotation.XmlType; >> >> >> /** >> * <p>Java class for echoVoidResponse complex type. >> * >> * <p>The following schema fragment specifies the expected content >> contained within this class. >> * >> * <pre> >> * <complexType name="echoVoidResponse"> >> * <complexContent> >> * <restriction base="{http://www.w3.org/2001/XMLSchema}anyType";> >> * <sequence> >> * </sequence> >> * </restriction> >> * </complexContent> >> * </complexType> >> * </pre> >> * >> * >> */ >> @XmlAccessorType(XmlAccessType.FIELD) >> @XmlType(name = "*echoVoidResponse*") >> public class EchoVoidResponse { >> >> >> } >> >> This is referred by another class generated by CXF like this: >> >> @RequestWrapper(localName = "echoVoid", targetNamespace = >> "TestWebServiceNS", className = "testwebservicens.EchoVoid") >> @WebMethod(action = "lde:echoVoid") >> @ResponseWrapper(localName = "*echoVoidResponse*", targetNamespace = >> "TestWebServiceNS", className = "testwebservicens.EchoVoidResponse") >> public void echoVoid(); >> >> >> - Then if "!boi.getOutput().getMessageParts().isEmpty()" evaluates to >> false then there is actual data on the wire? Would there be no "data" for >> "void"? >> >> Thank you, >> Gary >> >> On Thu, Mar 21, 2019 at 8:17 PM Andriy Redko <[email protected]> wrote: >> >>> Hey Gary, >>> >>> I think the interpretation is different. The if >>> (!boi.getOutput().getMessageParts().isEmpty()) states the >>> expecations that response should not be empty. The resList variable >>> (which comes from resList = CastUtils.cast(inMsg.getContent(List.class)) a >>> few statements above) is the response indicator, if it is null (no response) >>> but boi.getOutput().getMessageParts().isEmpty() is "false", it means >>> response is expected but was not received. >>> I think the code is correct. Thank you. >>> >>> Best Regards, >>> Andriy Redko >>> >>> >>> >>> GG> In master, at >>> GG> >>> org.apache.cxf.endpoint.ClientImpl.processResult(ClientImpl.java:663), we >>> GG> throw a IllegalEmptyResponseException where I see: >>> >>> GG> if (!boi.getOutput().getMessageParts().isEmpty()) { >>> GG> //we were supposed to get some output, but didn't. >>> GG> throw new IllegalEmptyResponseException("Response >>> message >>> GG> did not contain proper response data." >>> GG> + " Expected: " + >>> GG> boi.getOutput().getMessageParts().get(0).getConcreteName()); >>> GG> } >>> >>> GG> The test does not seem right: >>> >>> GG> !boi.getOutput().getMessageParts().isEmpty() >>> >>> GG> Should the "!" really be there if we want an error is there is no >>> response? >>> >>> GG> Gary >>> >>>
