0 Replies Latest reply on Aug 8, 2012 3:30 AM by amitsoprna

    JBOSS 6.1 final: war deployment giving class cast exception, classloader issue ?

    amitsoprna

      I 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!!