2 Replies Latest reply on Oct 2, 2007 4:54 PM by Nathan Helder

    JBoss 4.2.1 and EJB 3.0 Redeployment

    Nathan Helder Newbie

      I have a stateless session bean that I'd like to make available to a number of war applications.

      I'd like to (occasionally) update that session bean and have the changes be immediately made available to those war applications.

      But it seems that no matter what I do, the redeploying of the session bean results in ClassCastExceptions being encountered when the web applications look up the session bean's interface. These exceptions persist until either the server is stopped/started or the war file is redeployed.

      My best guess is that there's a disconnect between the Tomcat and JBoss class cache... the EJB is undeployed from JBoss and JBoss clears it's cache. Then the EJB comes back, JBoss loads those classes, and is ready to go. But Tomcat still has a reference to the old class files, and thus when it does its JBoss lookup of the EJB's interface it gets what appears to be a "different" class than what it has cached (even though nothing in the interface has changed) and dies.

      ...is that a (somewhat) accurate description of what's happening? If so, is there some way to avoid the class conflict?

      A serialVersionUID seems like it would be a slick solution, but of course those can't be placed on interfaces. Another (crude) solution would be to catch the ClassCastException, somehow tell Tomcat to flush it's cache for that particular context, then try the lookup again... but perhaps there's a more standard solution out there...?

      Thanks in advance,

      - Nathan

        • 2. Re: JBoss 4.2.1 and EJB 3.0 Redeployment
          Nathan Helder Newbie

          Thanks for that link jaikiran, it pointed me in the right direction.

          For those curious, here's how I applied the details from that link to a ejb/war setting:

          Create one (NetBeans) EJB project that contains only:

          Create a second EJB project that contains:

          And then a war project that attempts to make use of the local interface.

          The build file for the interfaces project produces a .jar with only the Local and Remote classes (no .xml files or other items), and deploys that .jar file to %JBOSS_HOME%/server/default/deploy

          The build file for the bean project produces a .jar with the SessionBean.class file and any other items needed to deploy the bean (i.e. jboss.xml) and deploys that .jar file to the same location as the previous.

          Both the bean project and the war project include references to the interfaces .jar (so they can be compiled), but don't package the interfaces .jar into their own .jar/.war files.

          Deploy the interfaces first...
          Then the bean...
          Then the war...
          And everything works fine.

          Redeploy just the bean project, and everything still works fine - no ClassCastExceptions encountered.

          So yeah, thanks again!

          - Nathan

          PS. In my first stab, both the interfaces and the bean files had the same package - ejb.test. This created problems when it came time for the war file to do its lookup (ClassCastExceptions once again). Splitting the interfaces and bean classes into two separate packages resolved that problem.