4 Replies Latest reply on Jan 24, 2008 12:00 PM by starksm64

    EJBTHREE-1173 and Beta4

    alrubinger

      This issue is worthy of special note, introduced in Beta3.

      My opinion is that we make an exception and fix it in both the EJB3 AS Module and EJB3 Core in Projects such that its fix can make Beta4. (EJB3 in Beta4 will not be based on the Mavenized component).

      Please weigh in.

      S,
      ALR

        • 1. Re: EJBTHREE-1173 and Beta4
          dimitris

          In addition to that, Emmanuel produced a new HEM beta to resolve http://opensource.atlassian.com/projects/hibernate/browse/EJB-326, so could we make use of that, too?
          http://jira.jboss.com/jira/browse/JBAS-5137

          • 2. Re: EJBTHREE-1173 and Beta4
            wolfc

            EJBTHREE-1173: can be fixed anywhere as long as there is no regression and it's properly merged into trunk and core.

            EJB-326: is only part of the story. We also need the new shared web class loader. It is worth a shot to upgrade HEM and see if there is no regression though.

            • 3. Re: EJBTHREE-1173 and Beta4
              dimitris

              I've flipped AS trunk to the latest HEM release (3.3.2.Beta2).

              • 4. Re: EJBTHREE-1173 and Beta4
                starksm64

                As documented in EJBTHREE-1173, I added a hack to introduce a dependency on the timer service mbean in trunk as a temp fix. Carlo notes:


                I still want to see the injection of the timer service into the deployer explored. It should create an implicit dependency.

                Besides that way we properly establish which timer service are to be used by the containers.

                Hmm, I'm missing a piece of the puzzle. I want EJB containers to become EJB Stateful, while this problem suggests EJB containers to become proper MC beans. In the end I want to have this code:

                @Stateful // the container is a (level 1) bootstrap stateful session
                public class StatefulContainer
                {
                @Resource TimerServiceFactory timerServiceFactory; // Injected
                }

                Level 1: EJB with injection & interception (there is chicken egg problem here)
                Level 2: EJB with timers
                Level 3: EJB with passivation
                Level 4: Full EJB
                (there will be more, or less)

                So I'm catching up to the notion of MC control. That would mean an extra layer on top of MC for EJB functionality. And an EJB instance would actually be a MC bean instance (with EJB component meta data). That would leave interceptors in a void again.