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

[vinoth kumar (JIRA)]

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);	




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira