I guess I would start with taking your test case and building a war that would deploy on Tomcat and checking if the proper WSDL is OK there. Then try making the minimum modifications needed for WebLogic and seeing what happens. I wonder if it’s one of:
1) Picking up a different version of some lib from WL that has a bug. For example: a different version of wsdl4j. 2) Not even using CXF at all and using the JAX-WS impl built into WL. Possibly increase the LOG level and then do the ?wsdl URL and make sure there are logs from CXF that are processing that request. Dan > On Dec 3, 2015, at 4:07 PM, Mercader, Felix <felix.merca...@firstdata.com> > wrote: > > Hi Aki > > I tried but you said. The automatic WSDL that I got after deploying in > WebLogic successfully is similar but not identical. In fact, mine is quite > small. > > And the important bit... In your wsdl, where you have: > > <soap:body parts="parameters" use="literal"/> > > I have again: > > <soap:body use="literal"/> > > So clearly I am having the same problem again. I have no "parts" at all. > Quite puzzling :) > > Thanks > flx > > > -----Original Message----- > From: Aki Yoshida [mailto:elak...@gmail.com] > Sent: 03 December 2015 14:29 > To: users@cxf.apache.org > Subject: Re: CXF incorrect WSDL automatically generated ? Please help ! > > Hi Felix, > you'll have to check with weblogic people. we can't do nothing more from the > cxf side. > > maybe you can try the below test service with your web logic setup and see > how it generates its wsdl. > > https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blob;f=tools/javato/ws/src/test/java/org/apache/cxf/tools/fortest/headers/SomeHeaders.java > > and this is the expected wsdl by cxf. > > https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blob;f=tools/javato/ws/src/test/resources/org/apache/cxf/tools/java2wsdl/processor/internal/jaxws/expected/expected_someheaders.wsdl > > regards, aki > > > 2015-12-03 11:27 GMT+01:00 Mercader, Felix <felix.merca...@firstdata.com>: >> Hi Aki >> >> Thank you very much for your interest and responses. >> >> As an update, as you suggested, I was able to update to cxf 3.0.7. I can't >> use 3.1.4 at the moment as my webservice fails when I deploy in weblogic but >> well, I am ok with this. >> >> I just did it again, without using the plain wsdl. I promise you that the >> automatic generated wsdl is not included at all this "parts" attribute. I >> really don't know why. >> >> Of course I have a web.xml file, a cxf-servlet.xml file... and this is the >> first time I write a cxf servlet so maybe there is something wrong in my >> code, who knows. But it works wonderfully now. Do you want me to send any >> particular file/s to your particular address ? I can see the complete >> automatic wsld or my cxf-servlet.xml or other code so you can check. >> >> Also I see some warnings in the WebLogic server when deploying/starting the >> webservice. They say something about "Could not start WS-Discovery >> Service"... I don't think this is related but I don't know, some classes >> appear in the logs that I have no idea what they are. >> >> Thanks again for all your support, very much appreciated. >> flx >> >> >> -----Original Message----- >> From: Aki Yoshida [mailto:elak...@gmail.com] >> Sent: 03 December 2015 10:16 >> To: users@cxf.apache.org >> Subject: Re: CXF incorrect WSDL automatically generated ? Please help ! >> >> to add to what i said below, as the generated wsdl in your cxf setup and the >> plain cxf setup differs, i suspect that your cxf setup has some >> inconsistency, either having a duplicate very old cxf version being picked >> up that might have this incorrect behavior or something other than cxf is >> generating your wsdl. >> >> >> 2015-12-03 11:03 GMT+01:00 Aki Yoshida <elak...@gmail.com>: >>> the cxf (including version 2.7.12) should be generating the parts >>> attribute in that case and I don't understand why you needed to >>> manually add it. >>> >>> i just tried your sample (only changed the return type from your >>> custom type to String) with cxf-2.7.12 and I am getting the following >>> binding element. >>> >>> <wsdl:binding name="FelixSampleServiceSoapBinding" >>> type="tns:FelixSamplePort"> >>> <soap:binding style="document" >>> transport="http://schemas.xmlsoap.org/soap/http"/> >>> <wsdl:operation name="getParent"> >>> <soap:operation soapAction="" style="document"/> >>> <wsdl:input name="getParent"> >>> <soap:header message="tns:getParent" part="callerId" use="literal"> >>> </soap:header> >>> <soap:header message="tns:getParent" part="timestamp" use="literal"> >>> </soap:header> >>> <soap:header message="tns:getParent" part="signature" use="literal"> >>> </soap:header> >>> <soap:body parts="parameters" use="literal"/> >>> </wsdl:input> >>> <wsdl:output name="getParentResponse"> >>> <soap:body use="literal"/> >>> </wsdl:output> >>> </wsdl:operation> >>> </wsdl:binding> >>> >>> it has the parts parameter for the body element for this multi >>> parameters operation. >>> >>> >>> >>> 2015-12-03 9:54 GMT+01:00 Mercader, Felix <felix.merca...@firstdata.com>: >>>> Daniel / Aki... thank you very very much !!! My problem is now fixed. My >>>> webservice is working nice wonderfully and the header parameters are in >>>> the header only, not in the body too anymore. >>>> >>>> Let me show you how I fixed and ask you one more question please. >>>> >>>> Daniel, you were totally right about the "parts" attribute not boing >>>> in my WSDL. So this is how I fixed, changing >>>> >>>> <soap:body use="literal"> >>>> >>>> To >>>> >>>> <soap:body use="literal" parts="parameters"/> >>>> >>>> Even with this change, if I use now the online wsdl validator >>>> (https://www.wsdl-analyzer.com/), it tells me everything is fine in my >>>> wsdl now ! >>>> >>>> Now I am investigating a bit more about this parts attribute. But let me >>>> ask you... It is an automatic generated WSDL. And I really would like NOT >>>> to do any manual change to the WSDL. So why this attribute was not in the >>>> wsdl ? I needed your help to fix it. It does not seem obvious to me. >>>> >>>> This attribute is not appearing to me when deploying in WebLogic. Is this >>>> the desired behaviour ? is it a bug ? >>>> >>>> In other words, the question I really want to ask: can I do any change in >>>> the java code of my cxf web service so this attribute will appear so I >>>> don't need to do any manual change to the WSDL ? >>>> >>>> This is my current code for this getParent call: >>>> >>>> @WebResult (name="merchantHierarchyParentResponse") >>>> MerchantHierarchyParentResponseDTO >>>> getParent( >>>> @WebParam(name="institutionNumber") @XmlElement(required=true) >>>> String institutionNumber, >>>> @WebParam(name="clientNumber") String clientNumber, >>>> @WebParam(name="ourReference") String ourReference, >>>> @WebParam(name="accessMerch") String accessMerch, >>>> @WebParam(header=true, name="callerId") String callerId, >>>> @WebParam(header=true, name="timestamp") String timestamp, >>>> @WebParam(header=true, name="signature") String signature >>>> ); >>>> >>>> Thank you a million !!! You both helped me loads ! >>>> >>>> flx >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Daniel Kulp [mailto:dk...@apache.org] >>>> Sent: 02 December 2015 16:49 >>>> To: users@cxf.apache.org; Mercader, Felix >>>> Subject: Re: CXF incorrect WSDL automatically generated ? Please help ! >>>> >>>> This would be a bug in the that wsdl analyzer tool. Having multiple >>>> parts in the message is fine as long as only one of those parts is used >>>> for the soap:body. >>>> >>>> However, looking at the requirements from: >>>> http://ws-i.org/profiles/basicprofile-2.0-2010-11-09.html#WSDLMSGS >>>> >>>> I think the bug is around R2210. The soap:body in your wsdl isn’t having >>>> the “parts” on it at all. >>>> >>>> >>>> Anyway, my more complete question is: what does a CXF client (or the >>>> JAX-WS RI client) generate for the soap message. This could also be a bug >>>> in SOAPUI. I believe both the RI and CXF will properly recognize that >>>> those parts are headers and not put them in the body. >>>> >>>> Dan >>>> >>>> >>>> >>>>> On Dec 2, 2015, at 5:20 PM, Mercader, Felix >>>>> <felix.merca...@firstdata.com> wrote: >>>>> >>>>> Hi Aki >>>>> >>>>> Thanks a million for your support ! Please help me again with what I >>>>> discovered below: >>>>> >>>>> To answer your questions, this is how it looks the wsdl:operation element >>>>> under the wsdl:binding element: >>>>> >>>>> >>>>> <wsdl:binding name="ServiceImplServiceSoapBinding" type="tns:IService"> >>>>> <soap:binding style="document" >>>>> transport="http://schemas.xmlsoap.org/soap/http"/> >>>>> <wsdl:operation name="getParent"> >>>>> <soap:operation soapAction="" style="document"/> >>>>> <wsdl:input name="getParent"> >>>>> <soap:header encodingStyle="" message="tns:getParent" >>>>> part="callerId" use="literal"/> >>>>> <soap:header encodingStyle="" message="tns:getParent" >>>>> part="timestamp" use="literal"/> >>>>> <soap:header encodingStyle="" message="tns:getParent" >>>>> part="signature" use="literal"/> >>>>> <soap:body use="literal"/> >>>>> </wsdl:input> >>>>> <wsdl:output name="getParentResponse"> >>>>> <soap:body use="literal"/> >>>>> </wsdl:output> >>>>> </wsdl:operation> >>>>> >>>>> >>>>> And now, let me add something I found that I think it can be very >>>>> interesting. I found this website in the Internet: >>>>> https://www.wsdl-analyzer.com/ >>>>> >>>>> If I put my WSDL (the one generated in WebLogic, I did not change >>>>> anything!). It tells me it has one error for each of the calls that the >>>>> WebService is offering. In this case, for the getParent is telling me >>>>> this as an error: >>>>> >>>>> The operation 'getParent' uses the message 'getParent' which has >>>>> more than one part. >>>>> >>>>> The getParent in the WSDL is as following: >>>>> >>>>> <wsdl:message name="getParent"> >>>>> <wsdl:part element="tns:getParent" name="parameters"/> >>>>> <wsdl:part element="tns:callerId" name="callerId"/> >>>>> <wsdl:part element="tns:timestamp" name="timestamp"/> >>>>> <wsdl:part element="tns:signature" name="signature"/> >>>>> </wsdl:message> >>>>> >>>>> So it has "more than one part". Then I did this change (manual change >>>>> which I really wouldn't like to do any manual change, but just as a test): >>>>> >>>>> <xs:element name="getParentType" type="tns:getParentType"/> >>>>> <xs:complexType name="getParentType"> >>>>> <xs:sequence> >>>>> <xs:element name="parameters" type="tns:getParent"/> >>>>> <xs:element name="callerId" type="tns:callerId"/> >>>>> <xs:element name="timestamp" type="tns:timestamp"/> >>>>> <xs:element name="signature" type="tns:signature"/> >>>>> </xs:sequence> >>>>> </xs:complexType> >>>>> >>>>> ... >>>>> >>>>> <wsdl:message name="getParent"> >>>>> <wsdl:part element="tns:getParentType" name="Wrapper"/> >>>>> </wsdl:message> >>>>> >>>>> So now the getParent is only 1 part. And in fact, if I use the website >>>>> https://www.wsdl-analyzer.com/, now it tells me that the WSDL is correct. >>>>> But unfortulately, if I deploy the WebService in WebLogic pointing to >>>>> this local and manually changed WSDL (adding wsdlLocation="..." in my >>>>> cxf_servlet.xml file)... then it fails at deploying time in WebLogic with >>>>> a strange java.lang.NullPointerException: >>>>> >>>>> <02-Dec-2015 16:14:18 o'clock GMT> <Error> <HTTP> <BEA-101216> <Servlet: >>>>> "cxf" failed to preload on startup in Web application: >>>>> "omniWebService_VAPP_war_exploded". >>>>> org.springframework.beans.factory.BeanCreationException: Error >>>>> creating bean with name 'omniWebService': Invocation of init method >>>>> failed; nested exception is javax.xml.ws.WebSe >>>>> rviceException: java.lang.NullPointerException >>>>> at >>>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1422) >>>>> at >>>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:518) >>>>> at >>>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:455) >>>>> at >>>>> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:293) >>>>> at >>>>> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222) >>>>> Truncated. see log file for complete stacktrace Caused By: >>>>> javax.xml.ws.WebServiceException: java.lang.NullPointerException >>>>> at >>>>> org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:371) >>>>> at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:251) >>>>> at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:539) >>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>> at >>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88) >>>>> Truncated. see log file for complete stacktrace Caused By: >>>>> java.lang.NullPointerException >>>>> at >>>>> org.apache.cxf.common.util.ASMHelper.getClassCode(ASMHelper.java:209) >>>>> at >>>>> org.apache.cxf.jaxws.WrapperClassGenerator.generateMessagePart(WrapperClassGenerator.java:310) >>>>> at >>>>> org.apache.cxf.jaxws.WrapperClassGenerator.createWrapperClass(WrapperClassGenerator.java:224) >>>>> at >>>>> org.apache.cxf.jaxws.WrapperClassGenerator.generate(WrapperClassGenerator.java:132) >>>>> at >>>>> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:683) >>>>> Truncated. see log file for complete stacktrace >>>>>> >>>>> <02-Dec-2015 16:14:18 o'clock GMT> <Error> <Deployer> <BEA-149265> >>>>> <Failure occurred in the execution of deployment request with ID >>>>> "24274166714283537" for task "127". Error is: >>>>> "weblogic.application.ModuleException: java.lang.NullPointerException" >>>>> weblogic.application.ModuleException: java.lang.NullPointerException >>>>> at >>>>> weblogic.application.internal.ExtensibleModuleWrapper.start(ExtensibleModuleWrapper.java:140) >>>>> at >>>>> weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:124) >>>>> at >>>>> weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:216) >>>>> at >>>>> weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:211) >>>>> at >>>>> weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42) >>>>> Truncated. see log file for complete stacktrace Caused By: >>>>> java.lang.NullPointerException >>>>> at >>>>> org.apache.cxf.common.util.ASMHelper.getClassCode(ASMHelper.java:209) >>>>> at >>>>> org.apache.cxf.jaxws.WrapperClassGenerator.generateMessagePart(WrapperClassGenerator.java:310) >>>>> at >>>>> org.apache.cxf.jaxws.WrapperClassGenerator.createWrapperClass(WrapperClassGenerator.java:224) >>>>> at >>>>> org.apache.cxf.jaxws.WrapperClassGenerator.generate(WrapperClassGenerator.java:132) >>>>> at >>>>> org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.generatedWrapperBeanClass(JaxWsServiceFactoryBean.java:683) >>>>> Truncated. see log file for complete stacktrace >>>>>> >>>>> <02-Dec-2015 16:14:18 o'clock GMT> <Error> <Deployer> <BEA-149202> >>>>> <Encountered an exception while attempting to commit the 9 task for >>>>> the application "omniWebService_VAPP_war_e xploded".> >>>>> >>>>> >>>>> Any help with this please ? >>>>> >>>>> Thanks >>>>> flx >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Aki Yoshida [mailto:elak...@gmail.com] >>>>> Sent: 02 December 2015 15:14 >>>>> To: users@cxf.apache.org >>>>> Subject: Re: CXF incorrect WSDL automatically generated ? Please help ! >>>>> >>>>> cxf-2.7.12 isn't so old and it shouldn't be generating the wrong wsdl for >>>>> the headers. >>>>> how does the corresponding wsdl:operation element under the wsdl:binding >>>>> element look like? >>>>> >>>>> >>>>> 2015-12-02 13:33 GMT+01:00 Mercader, Felix <felix.merca...@firstdata.com>: >>>>>> Thanks Aki >>>>>> >>>>>> I am using CXF version 2.7.12 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Aki Yoshida [mailto:elak...@gmail.com] >>>>>> Sent: 02 December 2015 12:26 >>>>>> To: users@cxf.apache.org >>>>>> Cc: Mercader, Felix >>>>>> Subject: Re: CXF incorrect WSDL automatically generated ? Please help ! >>>>>> >>>>>> which cxf version are you using? >>>>>> it could be an old bug. >>>>>> >>>>>> Questions should go to users@cxf, so I have moved this thread to there.. >>>>>> >>>>>> >>>>>> 2015-12-02 13:07 GMT+01:00 Felix.1973 <felix.merca...@omnipaygroup.com>: >>>>>>> Hi there. I am fighting the last two days with the same problem >>>>>>> and I don't know how to fix this. Even not sure if it is an error or >>>>>>> not. >>>>>>> >>>>>>> I have a CXF Web Service with something I consider very strange >>>>>>> and I would like to fix. This is one of the calls that the Web Service >>>>>>> deals with: >>>>>>> >>>>>>> @WebResult (name="merchantHierarchyParentResponse") >>>>>>> MerchantHierarchyParentResponseDTO >>>>>>> getParent( >>>>>>> @WebParam(name="institutionNumber") >>>>>>> @XmlElement(required=true) String institutionNumber, >>>>>>> @WebParam(name="clientNumber") String clientNumber, >>>>>>> @WebParam(name="ourReference") String ourReference, >>>>>>> @WebParam(name="accessMerch") String accessMerch, >>>>>>> @WebParam(header=true, name="callerId") String callerId, >>>>>>> @WebParam(header=true, name="timestamp") String timestamp, >>>>>>> @WebParam(header=true, name="signature") String signature >>>>>>> ); >>>>>>> >>>>>>> As you can see, it receives 4 normal parameters plus 3 extra >>>>>>> parameters in the header (callerId, timestamp and signature). >>>>>>> >>>>>>> It compiles successfully. Then I deploy it also successfully in a >>>>>>> WebLogic server. >>>>>>> >>>>>>> Finally, I use SoapUI to test it. I provide SoapUI with the URL >>>>>>> that WebLogic is providing me with the WSDL. This is, I am not >>>>>>> doing any change in the automatic generated WSDL. This is what I >>>>>>> am getting for this getParent in SoupUI: >>>>>>> >>>>>>> <soapenv:Envelope >>>>>>> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; >>>>>>> xmlns:web="http://webService.webservice.omnipay.com.server/";> >>>>>>> <soapenv:Header> >>>>>>> * <web:signature>?</web:signature> >>>>>>> <web:timestamp>?</web:timestamp> >>>>>>> <web:callerId>?</web:callerId>* >>>>>>> </soapenv:Header> >>>>>>> <soapenv:Body> >>>>>>> <web:getParent> >>>>>>> <institutionNumber>?</institutionNumber> >>>>>>> >>>>>>> <clientNumber>?</clientNumber> >>>>>>> >>>>>>> <ourReference>?</ourReference> >>>>>>> >>>>>>> <accessMerch>?</accessMerch> >>>>>>> </web:getParent> >>>>>>> /* <web:callerId>?</web:callerId> >>>>>>> <web:timestamp>?</web:timestamp> >>>>>>> <web:signature>?</web:signature>*/ >>>>>>> </soapenv:Body> >>>>>>> </soapenv:Envelope> >>>>>>> >>>>>>> My question is very clear. I see the 3 parameters in the header >>>>>>> section (callerId, timestamp and signature) but why these 3 >>>>>>> parameters are *AGAIN* at the end in the body part ??? I don't >>>>>>> want them in the body part, I want them only in the header. >>>>>>> >>>>>>> Any idea why this is happening ? Is that normal ? is it a bug ? >>>>>>> Thank you for your help ! >>>>>>> >>>>>>> thanks >>>>>>> Felix Mercader >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> View this message in context: >>>>>>> http://cxf.547215.n5.nabble.com/CXF-incorrect-WSDL-automatically- >>>>>>> g en e r ated-Please-help-tp5763489.html Sent from the cxf-dev >>>>>>> mailing list archive at Nabble.com. >>>>>> >>>>>> The information in this message may be proprietary and/or confidential, >>>>>> and protected from disclosure. If the reader of this message is not the >>>>>> intended recipient, or an employee or agent responsible for delivering >>>>>> this message to the intended recipient, you are hereby notified that any >>>>>> dissemination, distribution or copying of this communication is strictly >>>>>> prohibited. If you have received this communication in error, please >>>>>> notify First Data immediately by replying to this message and deleting >>>>>> it from your computer. >>>>> >>>>> The information in this message may be proprietary and/or confidential, >>>>> and protected from disclosure. If the reader of this message is not the >>>>> intended recipient, or an employee or agent responsible for delivering >>>>> this message to the intended recipient, you are hereby notified that any >>>>> dissemination, distribution or copying of this communication is strictly >>>>> prohibited. If you have received this communication in error, please >>>>> notify First Data immediately by replying to this message and deleting it >>>>> from your computer. >>>> >>>> -- >>>> Daniel Kulp >>>> dk...@apache.org - http://dankulp.com/blog Talend Community Coder - >>>> http://coders.talend.com >>>> >>>> >>>> The information in this message may be proprietary and/or confidential, >>>> and protected from disclosure. If the reader of this message is not the >>>> intended recipient, or an employee or agent responsible for delivering >>>> this message to the intended recipient, you are hereby notified that any >>>> dissemination, distribution or copying of this communication is strictly >>>> prohibited. If you have received this communication in error, please >>>> notify First Data immediately by replying to this message and deleting it >>>> from your computer. >> >> The information in this message may be proprietary and/or confidential, and >> protected from disclosure. If the reader of this message is not the intended >> recipient, or an employee or agent responsible for delivering this message >> to the intended recipient, you are hereby notified that any dissemination, >> distribution or copying of this communication is strictly prohibited. If you >> have received this communication in error, please notify First Data >> immediately by replying to this message and deleting it from your computer. > > The information in this message may be proprietary and/or confidential, and > protected from disclosure. If the reader of this message is not the intended > recipient, or an employee or agent responsible for delivering this message to > the intended recipient, you are hereby notified that any dissemination, > distribution or copying of this communication is strictly prohibited. If you > have received this communication in error, please notify First Data > immediately by replying to this message and deleting it from your computer. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
