Soap service works locally, but ClassCast exception is raised on another server

Can someone please help me with a strange problem?

I have a service:

@WebMethod @WebResult(name = "sendCustomerCommunicationResponse", targetNamespace = "......something/Underwriting/Correspondance/V1", partName = "Body") public SendCustomerCommunicationResponse sendCustomerCommunication( @WebParam(name = "sendCustomerCommunicationRequest", targetNamespace = "........something/Underwriting/Correspondance/V1", partName = "Body") SendCustomerCommunicationRequest body) throws ServiceException_Exception, SystemException_Exception ; 

And locally I call it with:

 SendCustomerCommunicationResponse response = correspondanceServicePort.sendCustomerCommunication(sendCustomerCommunicationRequest); 

And it works well. But when I deploy the application to another server, I get:

 "java.lang.ClassCastException: it.usi.xframe.ub1.batch.services.esb.SendCustomerCommunicationRequest incompatible with it.usi.xframe.ub1.batch.services.esb.SendCustomerCommunicationResponse" 

PS The application runs on a WebSphere server

Request:

 <soapenv:Envelope ...someSchema...> <soapenv:Header> <v1:TechnicalHeader> <v1:correlationId>12742</v1:correlationId> <v1:sender>userName</v1:sender> <v1:countryCode/> <v1:channelId/> <v1:userID>userName</v1:userID> <v1:operationId>CHANGE_STATUS</v1:operationId> </v1:TechnicalHeader> <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"> <wsse:UsernameToken> <wsse:Username>someUser</wsse:Username> <wsse:Password>somePassoword</wsse:Password> </wsse:UsernameToken> </wsse:Security> </soapenv:Header> <soapenv:Body> <v11:sendCustomerCommunicationRequest> <v11:eventCode>{"header":{"publishingDate":1474016634749,"eventId":"DEL-NEG","applicationCode":"UB3","correlationId":"9999","language":"IT","channelId":"MOB"},"body":{"ndg":"5106215","additionalInfo":{}}}</v11:eventCode> </v11:sendCustomerCommunicationRequest> </soapenv:Body> </soapenv:Envelope> 
+5
source share
4 answers

This might be a WebSphere JAXB issue related to the version you are using, or your server might miss some fixes. See what the docs say :

Unmarshaller JAXB generates stub classes at runtime to help expose the document. These generated classes are cached and can be reused by other JAXBContexts in the application.

When a JAXBContext contains a class that has an element template (i.e. @XmlAnyElement ), it is possible that Unmarshaller will use incompatible generated stub classes from another JAXBContext , which could ClassCastException during ClassCastException . The problem was solved by improving the collision. The check is performed on previously generated stub classes so that a new stub class is generated from the current JAXBContext if the previously created stub class found in the cache is incompatible.

It's hard to guess because of the nature of IBM, regardless of the version you are using. Also, see other fixes:

+1
source

It seems the problem is with the server (or with the request).

When the server processes the request, it simply drops it back. The message payload was not changed (for any reason), and there were no exceptions.

Therefore, when it returns and is impossible, this is not an example of SendCustomerCommunicationResponse , but SendCustomerCommunicationRequest

I can first suggest SOAPUI (with a sample request) or tcpMon between the client and server to find out what the exact request and response from the server is.

+1
source

Q:

  • How is SendCustomerCommunicationResponse defined? Does @Xml.. annotations? (e.g. @XmlRoot ..
  • just for testing, you could set the name of the returned variable @WebResult for something other than the name of the returned class ( SendCustomerCommunicationResponse )
  • What are SystemException_Exception and SystemException_Exception ? your own exceptions? These seem to be JAX-RS / JAXB exceptions.
+1
source

It looks like a class version mismatch problem.

One of the scenarios in which developers create Web-Service stubs and create them in their project using a newer version, while the classpath class has an older version of some dependent jar files. I would recommend the following steps to eliminate this option for inappropriate dependency versions.

  • Get the dependency tree and files that do not work. You should get a list of dependent jar files. (Check out the specific jar file that is responsible for creating the Request and Response objects on your local computer).
  • Compare the class path on the WebSphere server and add the missing jars.
  • replace any dependent jar files in the path to the WebSphere classes if they belong to an older version.

A second approach may be to remotely debug, if possible, after enabling the decompiler in your IDE. Check the class files in which the exception occurs and make sure that the editor is associated with the navigator view so that your navigator displays the file in the bank that has been debugged. You should be able to find the exact jar file that is called during the exception.

+1
source

Source: https://habr.com/ru/post/1261319/


All Articles