[jbossws-issues] [JBoss JIRA] Commented: (JBWS-2742) Getting Classcast Exception Inconsistently with the WSAddressing Implemented Services

Getting Classcast Exception Inconsistently with the WSAddressing Implemented Services ------------------------------------------------------------------------------------- Key: JBWS-2742 URL: https://jira.jboss.org/jira/browse/JBWS-2742 Project: JBoss Web Services Issue Type: Bug Security Level: Public(Everyone can see) Components: jbossws-native Affects Versions: jbossws-native-3.1.0 Environment: Linux - Ubuntu Reporter: vinoth kumar We are using JBOSS 4.2.3 with JBOSSWS Native 3.1.0 deployed. We had implemented WSAddressing for Our Services as per the Steps given in the link : http://www.jboss.org/community/wiki/JBossWS-NativeUserGuide. This WSAddressing implementation works fine without any issues if we give a single hit to the Services from the client for a given time. But if we have multiple simultaneous hits, we are getting the Classcast Exception inconsistently. We had done the following changes in Client, Code: Service service = Service.create(wsdlURL, serviceName); port1 = (IdentityServiceImpl)service.getPort(IdentityServiceImpl.class); BindingProvider bindingProvider = (BindingProvider)port1; List<Handler> customHandlerChain = new ArrayList<Handler>(); customHandlerChain.add(new ClientHandler()); customHandlerChain.add(new WSAddressingClientHandler()); bindingProvider.getBinding().setHandlerChain(customHandlerChain); The Exception that we are getting is, Code: javax.xml.ws.WebServiceException: java.lang.ClassCastException: com.mobax.signage.ws.RemoveDeviceResponse cannot be cast to com.mobax.signage.ws.GetDeviceResponseRe sponse at org.jboss.ws.core.jaxws.client.ClientImpl.handleRemoteException(ClientImpl.java:404) at org.jboss.ws.core.jaxws.client.ClientImpl.invoke(ClientImpl.java:314) at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:172) at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:152) at $Proxy103.removeDevice(Unknown Source) at com.mobax.mashup.webserviceconsumer.SignageServiceConsumer.removeDevices(SignageServiceConsumer.j ava:264) at com.mobax.mashup.responsebuilder.EnablerResponseParser.removeDevice(EnablerResponseParser.java:14 89) at com.mobax.mashup.servlet.signage.RemoveDevice.processRequest(RemoveDevice.java:60) at com.mobax.mashup.servlet.signage.RemoveDevice.doGet(RemoveDevice.java:88) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446) at java.lang.Thread.run(Thread.java:619) As per Our understanding, We are invoking the method port1.getDeviceResponse() . Before receiving the response for this request, we are invoking another method port1.removeDevice() . The Proxy seems to be waiting for the Response for the second request removeDevice() . When it receives the Response for the first request getDeviceResponse(), the proxy tries to parse this response assuming that this response belongs to the Second request, thus Resulting in Classcast Exception. We would like to know whether anybody have Successfully implemented the WSAddressing in their Services without having any issues. Interestingly, we had find out a WORKAROUND for this issue. The workaround is to generate the following code for every Request. i.e., before calling any Requests, if we generate the following proxy every time newly, then the Exception does not Occurs. Code: port1 = (IdentityServiceImpl)service.getPort(IdentityServiceImpl.class); BindingProvider bindingProvider = (BindingProvider)port1; List<Handler> customHandlerChain = new ArrayList<Handler>(); customHandlerChain.add(new ClientHandler()); customHandlerChain.add(new WSAddressingClientHandler()); bindingProvider.getBinding().setHandlerChain(customHandlerChain);