On Nov 18, 2013, at 4:29 AM, Euan Milton <euanmil...@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: euanmil...@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: elak...@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 <euanmil...@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 dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
