glassfish
  1. glassfish
  2. GLASSFISH-622

dependency injection not working at ProstActivate

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 9.0pe
    • Fix Version/s: 9.0pe
    • Component/s: ejb_container
    • Labels:
      None
    • Environment:

      Operating System: Windows 2000
      Platform: All

    • Issuezilla Id:
      622

      Description

      This test was verifyed with Glassfish b46.

      A Stateful Session Bean recieves several resource injections, releases some of
      them at @PrePassivate an does not recives them back at PostActivate.

      According do EJB 3 Simplified API spec final draft:
      5.1.5 Dependency Injection
      If a stateful session bean uses dependency injection mechanisms for the
      acquisition of references to resources or other objects in its environment (see
      Chapter 8), the container injects these references before any business methods
      or lifecycle callback interceptor methods are invoked on the bean instance.

      @Stateful(name="procBonus", mappedName="procBonus")
      @Remote(value=ProcessoBonificacao.class)
      public class ProcessoBonificacaoBean implements ProcessoBonificacao {

      short ano;
      double bonusTotal;
      TreeMap ranking = null;
      @Resource SessionContext sessionCtx;
      @Resource(name="jdbc/dataSourceRH")
      public javax.sql.DataSource dataSourceRH;
      @Resource(mappedName="jms/QConnFactory")
      public javax.jms.QueueConnectionFactory jmsQConnFactory;
      @Resource(mappedName="jms/queueA") public javax.jms.Queue queue;

      // business methods ommited

      @PrePassivate
      public void release()

      { System.out.println("releasing resources..." + ano); dataSourceRH = null; queue = null; jmsQConnFactory = null; }

      @PostActivate
      public void recover()

      { System.out.println("re-activating... " + ano); System.out.println(dataSourceRH == null); System.out.println(jmsQConnFactory == null); System.out.println(queue == null); }


      }

      The bean has its business methods invoked by a remote client, and left idle for
      several minutes, waiting for the passivation. After that a business methos is
      invoked to force activation. At that point the resources are not being injected.

      The only workaround is to manually lookup the resources at PreActivate method -
      so there is no point in use dependency injection.

        Activity

        Hide
        ksak added a comment -

        The referenced spec section doesn't imply that injection takes place each time before postActivate is
        called. It's saying that in the the stateful session bean lifecycle, injection happens once sometime after
        the bean class' no-arg constructor is called and before any lifecycle callbacks methods/business
        methods could be called.

        The stateful session bean lifecycle diagram in Figure 5(page 74) of the Core contracts document shows
        this more clearly. Unfortunately, this is a spec issue and not an implementation bug. It is the bean
        developer's responsibility to manage objects that are not automatically handled during passivation.
        This is outlined starting in section 4.2.1 of the Core Contracts document. That would mean either
        marking those fields transient or nulling out their references in PrePassivate and doing the
        corresponding lookups in PostActivate.

        You're right that for these kinds of objects within stateful session beans, the benefit of injection is
        reduced. The spec team is aware of this usability issue so it's likely to be addressed within a future
        spec release. There is still a benefit to using annotations here, which is to avoid having to declare
        everything in the deployment descriptor. Every environment annotation corresponds to an entry within
        the component's naming context, which in EJB 3.0 can be more easily retrieved using the
        SessionContext.lookup method.

        @PostActivate
        public void recover()

        { System.out.println("re-activating... " + ano); dataSourceRH = (DataSource) sessionCtx.lookup("jdbc/dataSourceRH"); jmsQConnFactory = (QueueConnectionFactory) sessionCtx.lookup("jms/QConnFactory"); queue = (Queue) sessionCtx.lookup("jms/queueA"); }

        Show
        ksak added a comment - The referenced spec section doesn't imply that injection takes place each time before postActivate is called. It's saying that in the the stateful session bean lifecycle, injection happens once sometime after the bean class' no-arg constructor is called and before any lifecycle callbacks methods/business methods could be called. The stateful session bean lifecycle diagram in Figure 5(page 74) of the Core contracts document shows this more clearly. Unfortunately, this is a spec issue and not an implementation bug. It is the bean developer's responsibility to manage objects that are not automatically handled during passivation. This is outlined starting in section 4.2.1 of the Core Contracts document. That would mean either marking those fields transient or nulling out their references in PrePassivate and doing the corresponding lookups in PostActivate. You're right that for these kinds of objects within stateful session beans, the benefit of injection is reduced. The spec team is aware of this usability issue so it's likely to be addressed within a future spec release. There is still a benefit to using annotations here, which is to avoid having to declare everything in the deployment descriptor. Every environment annotation corresponds to an entry within the component's naming context, which in EJB 3.0 can be more easily retrieved using the SessionContext.lookup method. @PostActivate public void recover() { System.out.println("re-activating... " + ano); dataSourceRH = (DataSource) sessionCtx.lookup("jdbc/dataSourceRH"); jmsQConnFactory = (QueueConnectionFactory) sessionCtx.lookup("jms/QConnFactory"); queue = (Queue) sessionCtx.lookup("jms/queueA"); }

          People

          • Assignee:
            ksak
            Reporter:
            rbellia
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: