2 Replies Latest reply on Jul 19, 2005 5:48 PM by joco3

    EJB 3 hot deployment bug?

    joco3

      Hi,

      I've found some weird behavior related to EJB 3/hot-deployment.

      I have an EJB 3 entity. I tried to add a static field to the class, and initialize it with the static class initializer:

      static
      {
      init();
      }

      where init() is a static function that modifies the static field.

      It may not be allowed by the EJB specs (I'm quite new to this topic), but even if this is the case, please note the following! When I deployed the whole stuff in JBoss, the classloader could not pick up the entity-bean class. (it threw a NoClassDefFound error). Moreover, when I re-deployed the right version of the entity-bean (no static initializer) using hot-deployment, JBoss apparently did not load the new bytecode properly, because it threw a ClassCastException this time. (I guess the old bytecode got stuck in the classloader cache). However when I restarted the server, then the correct bytecode got picked up properly and the entity bean deployed fine.

      Have I found a bug, or am I just a lamer? :-)

      Btw. I'm using JBoss4.0.3RC1 (with EJB 3 Beta, obviously)

      joe

        • 1. Re: EJB 3 hot deployment bug?
          bill.burke

          Do you have copies of your entity bean class in different archives? Like a copy of the Entity bean within your war and another in your par? If so, then you will get CCE's if you only redeploy the .par.

          • 2. Re: EJB 3 hot deployment bug?
            joco3

            Hi,

            That would explain it, but no: I only have one copy of the entity bean within a single ear. I also tried it with a "clean" JBoss installation; when I drop the ear into the deploy folder, the hot-deployment fails with a NoClassDefFoundError.

            Some extra info: the entity is referred from the business interface of a stateless session bean (the interface has a method that takes a parameter of that entity-type.) Actually it's the deployment of the session bean that fails. I checked the session bean-MBean on the JMX-console and it says that it got stuck in "Starting" state...

            Does it help at all?