JBOSS 6.1 final: war deployment giving class cast exception, classloader issue ?
amitsoprna Aug 8, 2012 3:30 AMI want to deploy my war file in the JBOSS6.1 final. Following is my application structure (war is archieved and not exploaded)
myapplication.war
|----------META-INF
|----------WEB-INF
|--------classes ** My application classes
|--------lib
|-----my_application_specific_utility_classes.jar
|-----webservices-api.jar
|-----webservices-rt.jar ** and some other jars
I put this war in the jboss_home/server/my_application_server/deploy folder
When I run this server it gets deployed succesfully. But for some reason at run time when the server tries to assign object of a given class say "User" (which is there in my_application_specific_utility_classes.jar) returned by an EJB call to a different server instance. it throws the following exception
java.lang.ClassCastException: my.application.specific.utility.classes.User cannot be cast to my.application.specific.utility.classes.User
at $Proxy207.getUserByUserId(Unknown Source)
at my.application.specific.utility.classes.UserClientImpl.getUserByUserId(UserClientImpl.java:422)
at com.sun.xml.ws.api.server.InstanceResolver$1.invokeProvider(InstanceResolver.java:256)
at com.sun.xml.ws.server.InvokerTube$2.invokeProvider(InvokerTube.java:156)
at com.sun.xml.ws.server.provider.SyncProviderInvokerTube.processRequest(SyncProviderInvokerTube.java:78)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:598)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:557)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:542)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:439)
at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:243)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:471)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135)
at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doGet(WSServletDelegate.java:129)
at com.sun.xml.ws.transport.http.servlet.WSServletDelegate.doPost(WSServletDelegate.java:160)
at com.sun.xml.ws.transport.http.servlet.WSServlet.doPost(WSServlet.java:75)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:754)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:324)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:242)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:181)
at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.event(CatalinaContext.java:285)
at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.invoke(CatalinaContext.java:261)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:88)
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:100)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:159)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:53)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:654)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951)
at java.lang.Thread.run(Thread.java:619)
I have analysed that this is happening because the same jar "my_application_specific_utility_classes.jar" is used by the other project on this server instance that is causing this problem. Because if i remove that project the above call work fine and ClassCastException vanishes. Following is the other application's (which is an ear) structure:
mysecondapplication.ear
|----------META-INF
|----------my_application_specific_utility_classes.jar
|----------some_other.jar
|----------mysecondapplication.war
|----------META-INF
|----------WEB-INF
|--------classes ** My second application classes
|--------lib
|-----my_application_specific_utility_classes.jar
|-----some_other.jar
|-----some_other_two.jar ** and some other jars
Can anyone please let me know what's happening here, and what is the solution to avoid it.
The same architecture used to work in JBOSS4.2. Thanks!!