You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Euan Milton <eu...@hotmail.co.uk> on 2014/01/13 15:57:54 UTC
RE: Problems generating correct structure of SOAP message on WAS
using CXF generated client code
Thanks for this. I finally had some time to look into this and by ensuring that the CXF runtime is picked up rather than the Axis2 runtime has resulted in the problem being resolved.
However, I am interested in finding out what the problem with the Axis2 implementation is in this case, as we have examples of other web services that we have integrated with where we've used CXF for the client code generation and used Axis2 for runtime where it has worked fine. I'll pursue this with the Axis2 group.
Thanks for your help.
Euan
> Subject: Re: Problems generating correct structure of SOAP message on WAS using CXF generated client code
> From: dkulp@apache.org
> Date: Tue, 3 Dec 2013 14:33:34 -0500
> To: users@cxf.apache.org; euanmilton@hotmail.co.uk
>
>
> On Nov 18, 2013, at 4:29 AM, Euan Milton <eu...@hotmail.co.uk> wrote:
> Hi,
> > Does anyone have idea on this? I've explored all avenues I can so any help at all would be appreciated!
> > Cheers,
>
> > In WAS, the instance of the service client generated by the call to createServiceObject shown below is org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.
>
> You need to get that “figured” out first. The JAX-WS implementation that is being picked up is the buggy axis2 version that is included in WAS. You likely need to set the parent last class loader options and such to make sure CXF is picked up. That’s the first thing to try.
>
> The next thing would be to add -xjc-npa to the wsdl2java call to not generate the package-info.java things. The WAS classloaders sometime have problems grabbing the information out of the package-info. The -npa flag sticks all the information right into the objects. That can often be a huge help.
>
>
>
> Dan
>
>
>
>
>
> > Euan
> >
> > From: euanmilton@hotmail.co.uk
> > To: users@cxf.apache.org
> > Subject: RE: Problems generating correct structure of SOAP message on WAS using CXF generated client code
> > Date: Thu, 14 Nov 2013 15:51:15 +0000
> >
> >
> >
> >
> > Hi,
> > We've only used CXF to generate the client code to consume the web service.
> > In Tomcat, the instance of the service client generated by the call to createServiceObject shown below appears to be an instance of the native JAX-WS RI (JAX-WS RI 2.1.6).
> > In WAS, the instance of the service client generated by the call to createServiceObject shown below is org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.
> > However, like I mentioned earlier, I have generated web service client code using CXF many times before and have been able to successfully deploy the applications onto WAS without these issues.
> > Is there anything in the WSDL definition that may cause this problem in terms of the serialization not working correctly?
> > Cheers,
> > Euan
> >
> >
> >> Date: Thu, 14 Nov 2013 15:55:02 +0100
> >> Subject: Re: Problems generating correct structure of SOAP message on WAS using CXF generated client code
> >> From: elakito@gmail.com
> >> To: users@cxf.apache.org
> >>
> >> are you sure that cxf is used in both environments?
> >> i suspect something else is doing the work in WAS.
> >>
> >>
> >> 2013/11/14 Euan Milton <eu...@hotmail.co.uk>:
> >>> Hi all,
> >>>
> >>> We have a web application which needs to consume an external web service.
> >>> To do this we have generated the set of Java artifacts from the WSDL via Maven using the wsdl2java goal provided by the cxf-codegen-plugin Maven plugin. The SEI generated by CXF is then used to invoke the web service.
> >>> When we deploy the built web app on Tomcat everything works fine. However, when exactly the same web app is deployed on WebSphere Application Server, there are problems in terms of the serialized SOAP message that is created.
> >>> The SOAP request that is generated by the app deployed on Tomcat is:<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
> >>> <S:Body>
> >>> <ns12:ProcessUIRequest xmlns:ns10="http://zzz/yyyentityview/validation/"
> >>> xmlns:ns11="http://zzz/yyyview/search/list/"
> >>> xmlns:ns12="http://zzz/yyywebservice/v5/types/"
> >>> xmlns:ns2="http://zzz/yyyentityview/app/"
> >>> xmlns:ns3="http://zzz/yyyentityview/client/"
> >>> xmlns:ns4="http://zzz/yyyview/search/postcode/"
> >>> xmlns:ns5="http://zzz/yyyview/app/"
> >>> xmlns:ns6="http://zzz/yyyview/search/app/"
> >>> xmlns:ns7="http://zzz/yyyview/search/bank/"
> >>> xmlns:ns8="http://zzz/yyyview/uw/"
> >>> xmlns:ns9="http://zzz/yyybase/">
> >>> <ns12:ProcessUIRequest CallType="Submit" DisplayError="false"
> >>> IsAnonymous="false" IsCompactRequest="false" IsError="false">
> >>> <ns9:ModelData>
> >>> <ns9:TransactionData ApplicationReference="20000003CR3.00000003"
> >>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >>> xsi:type="ns5:QuoteLoadTxnDataVO" />
> >>> </ns9:ModelData>
> >>> <ns9:Activity ActionCode="QuoteLoad" ActionMode="Default"
> >>> ActivityCode="QuoteApplicationFull" ActivityMode="Default"
> >>> ActivityReference="" ActivityStatus="Inital"
> >>> ActivityTransaction="StartNewActivityAndLogOffUser"
> >>> CanProceedWithValidationsOutstanding="true">
> >>> <ns9:BusinessKeys>
> >>> <item>
> >>> <key>
> >>> <string>ADVREF</string>
> >>> </key>
> >>> <value>
> >>> <BusinessKeyVO KeyName="ADVREF" KeyValue="AVAGT01">
> >>> <BusinessKey KeyName="ADVREF" KeyType="Unknown"
> >>> KeyValue="AVAGT01" />
> >>> </BusinessKeyVO>
> >>> </value>
> >>> </item>
> >>> </ns9:BusinessKeys>
> >>> </ns9:Activity>
> >>> </ns12:ProcessUIRequest>
> >>> </ns12:ProcessUIRequest>
> >>> </S:Body>
> >>> </S:Envelope>
> >>> The POJO which is marshalled into that SOAP request is:
> >>> <tcp.ssgbase.BaseVO>
> >>> <modelData>
> >>> <transactionData class="tcp.ssgview.app.QuoteLoadTxnDataVO">
> >>> <applicationReference>20000003CR3.00000003</applicationReference>
> >>> </transactionData>
> >>> </modelData>
> >>> <activity>
> >>> <businessKeys>
> >>> <item>
> >>> <tcp.serializable__dictionary.BusinessKeyItem>
> >>> <key>
> >>> <string>ADVREF</string>
> >>> </key>
> >>> <value>
> >>> <businessKeyVO>
> >>> <businessKey>
> >>> <keyName>ADVREF</keyName>
> >>> <keyValue>AVAGT01</keyValue>
> >>> <keyType>Unknown</keyType>
> >>> </businessKey>
> >>> <keyName>ADVREF</keyName>
> >>> <keyValue>AVAGT01</keyValue>
> >>> </businessKeyVO>
> >>> </value>
> >>> </tcp.serializable__dictionary.BusinessKeyItem>
> >>> </item>
> >>> </businessKeys>
> >>> <actionMode>DEFAULT</actionMode>
> >>> <activityMode>DEFAULT</activityMode>
> >>> <activityTransaction>START_NEW_ACTIVITY_AND_LOG_OFF_USER</activityTransaction>
> >>> <actionCode>QuoteLoad</actionCode>
> >>> <activityReference></activityReference>
> >>> <activityStatus>INITAL</activityStatus>
> >>> <activityCode>QuoteApplicationFull</activityCode>
> >>> <canProceedWithValidationsOutstanding>true</canProceedWithValidationsOutstanding>
> >>> </activity>
> >>> <displayError>false</displayError>
> >>> <isAnonymous>false</isAnonymous>
> >>> <isError>false</isError>
> >>> <isCompactRequest>false</isCompactRequest>
> >>> <callType>SUBMIT</callType>
> >>> </tcp.ssgbase.BaseVO>
> >>> The SOAP request generated when the app is deployed on WAS is:
> >>> <soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
> >>> <soapenv:Body>
> >>> <ns2:ProcessUIRequest xmlns:ns2="http://zzz/yyywebservice/v5/types/">
> >>> <processUIRequest>
> >>> <activity>
> >>> <actionCode>QuoteLoad</actionCode>
> >>> <actionMode>DEFAULT</actionMode>
> >>> <activityCode>QuoteApplicationFull</activityCode>
> >>> <activityMode>DEFAULT</activityMode>
> >>> <activityReference />
> >>> <activityStatus>INITAL</activityStatus>
> >>> <activityTransaction>
> >>> START_NEW_ACTIVITY_AND_LOG_OFF_USER</activityTransaction>
> >>> <businessKeys />
> >>> <canProceedWithValidationsOutstanding>
> >>> true</canProceedWithValidationsOutstanding>
> >>> </activity>
> >>> <callType>SUBMIT</callType>
> >>> <displayError>false</displayError>
> >>> <isAnonymous>false</isAnonymous>
> >>> <isCompactRequest>false</isCompactRequest>
> >>> <isError>false</isError>
> >>> <modelData>
> >>> <transactionData xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >>> xsi:type="ns2:quoteLoadTxnDataVO">
> >>> <applicationReference>
> >>> 20000003ESF.00000018</applicationReference>
> >>> </transactionData>
> >>> </modelData>
> >>> </processUIRequest>
> >>> </ns2:ProcessUIRequest>
> >>> </soapenv:Body>
> >>> </soapenv:Envelope>
> >>> The POJO which is marshalled into that SOAP request is:
> >>> <tcp.ssgbase.BaseVO>
> >>> <modelData>
> >>> <transactionData class="tcp.ssgview.app.QuoteLoadTxnDataVO">
> >>> <applicationReference>20000003ESF.00000018</applicationReference>
> >>> </transactionData>
> >>> </modelData>
> >>> <activity>
> >>> <businessKeys>
> >>> <item>
> >>> <tcp.serializable__dictionary.BusinessKeyItem>
> >>> <key>
> >>> <string>ADVREF</string>
> >>> </key>
> >>> <value>
> >>> <businessKeyVO>
> >>> <businessKey>
> >>> <keyName>ADVREF</keyName>
> >>> <keyValue>AVAGT01</keyValue>
> >>> <keyType>Unknown</keyType>
> >>> </businessKey>
> >>> <keyName>ADVREF</keyName>
> >>> <keyValue>AVAGT01</keyValue>
> >>> </businessKeyVO>
> >>> </value>
> >>> </tcp.serializable__dictionary.BusinessKeyItem>
> >>> </item>
> >>> </businessKeys>
> >>> <actionMode>DEFAULT</actionMode>
> >>> <activityMode>DEFAULT</activityMode>
> >>> <activityTransaction>START_NEW_ACTIVITY_AND_LOG_OFF_USER</activityTransaction>
> >>> <actionCode>QuoteLoad</actionCode>
> >>> <activityReference></activityReference>
> >>> <activityStatus>INITAL</activityStatus>
> >>> <activityCode>QuoteApplicationFull</activityCode>
> >>> <canProceedWithValidationsOutstanding>true</canProceedWithValidationsOutstanding>
> >>> </activity>
> >>> <displayError>false</displayError>
> >>> <isAnonymous>false</isAnonymous>
> >>> <isError>false</isError>
> >>> <isCompactRequest>false</isCompactRequest>
> >>> <callType>SUBMIT</callType>
> >>> </tcp.ssgbase.BaseVO>
> >>>
> >>> You can see that the structure of the two requests are different even though the code being executed on both servers is exactly the same and the structure of the POJOs used to create the SOAP message is the same (barring one value). The message produced on Tomcat is the correct one.
> >>> If you look at the structure of the <activity> object in each message, you can see that in the message produced by on Tomcat, the majority of the data is produced as attributes, whereas in the message produced on WAS contains everything as actual child nodes of activity. As per the WSDL and XSD definition of the web service interface, the request produced on Tomcat is correct.
> >>> Our code to generate the correct service endpoint interface implementation is:
> >>> private <T> T createServiceObject(final Class<T> p_seiClass) throws ApplicationException {
> >>> try {
> >>> final Service serviceFactory = Service.create(new URL(wsdlLocation), new QName(targetNamespace, serviceName));
> >>>
> >>> final SoapHandlerResolver handlerResolver = new SoapHandlerResolver();
> >>> handlerResolver.addHandler(new SoapMessageLoggingHandler());
> >>> serviceFactory.setHandlerResolver(handlerResolver);
> >>>
> >>> final T service = serviceFactory.getPort(p_seiClass);
> >>> ((BindingProvider) service).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
> >>> "endpoint");
> >>>
> >>> return service;
> >>> } catch (MalformedURLException e) {
> >>> throw new ApplicationException(ApplicationErrorCode.COMM_ERR_UNEXPECTED_ERROR, e);
> >>> }
> >>> }
> >>> I've used the same mechanism to call many other web services before with applications deployed on WAS and never had this problem.
> >>> Does anyone have any ideas as to what the underlying issue could be? Or any pointers as to where I could investigate further? I'm at a bit of a dead end at the moment and have already spent quite a bit of time investigating the issue.
> >>> Thanks for your help in advance.
> >>> Euan
> >>>
> >>>
> >>>
> >
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>