5 Replies Latest reply on Feb 14, 2007 3:27 PM by Carlo de Wolf

    Transient re-injection

    Carlo de Wolf Master

      I'm looking at the stateful unit test and in StatefulBean there are two transient fields which are supposed to be re-injected after activation. This is not according to spec, where injection takes place after construction of the object (4.3.2). The bean provider is supposed to make the bean serializable (4.2.1) and re-animate it on activation.

      I like the way it is in the unit test code though, so we should make this a JBoss explicit extension (and get it into the spec later).

      Let's say the following:
      Any field which has an injection annotation and which is transient will be re-injected upon activation. Unless in jboss.xml reinjection is set to false.

      (The containers should keep an extra list of reinjectors.)

        • 1. Re: Transient re-injection
          Bill Burke Master

          Is there a TCK test for this? If not, then keep it as it is, IMO.

          • 2. Re: Transient re-injection
            William DeCoste Apprentice

            The spec is a little vague on what is allowed to be passivated/activated vs what is re-injected or what must be reset in the lifecycle methods. The question is what is an "open resource". The test with the transient field and the resultant re-injection came about because of an old support or forum issue.


            In advanced cases, a session object?s conversational state may contain open resources, such as open
            sockets and open database cursors. A container cannot retain such open resources when a session bean
            instance is passivated. A developer of a stateful session bean must close and open the resources in the
            PrePassivate and PostActivate lifecycle callback interceptor methods.[8]


            • 3. Re: Transient re-injection
              Carlo de Wolf Master

              I think 4.2.1 is pretty clear on what is allowed to be in the bean after PrePassivate. As you spotted yourself it's the bean provider's responsibility to handle open resources.

              I definitely want to keep this functionality, but "as is" is broken right now. :-)
              I don't want it to end up in the injection module, so I want state that it's an EJB functionality (specifically for SFSB) and code it accordingly.

              • 4. Re: Transient re-injection
                Bill Burke Master

                Carlo: Bean Provider == Application Developer. The APp developer is responsible for closing connections.

                Also, i see nothing in the spec that supports your claims. 4.2.1 says that the container is allowed to use ObjectStreamClass techniques for injected things, which is what we do. Furthermore, constructor invocations don't even happen in Java serialization. How EJB3.0 works now is basically the same on how it worked in our old container.

                The problem with the idea of reinjection, is that there may be state associated with the previous injected reference. I.E. Extended persistence contexts, SFSB references.

                • 5. Re: Transient re-injection
                  Carlo de Wolf Master

                  That's what I keep saying, all these transient fields are not our problem but the app / bean developers problem. So we could lose the functionality all together.

                  The Bean Provider must assume that the content of transient ?elds may be lost between the PrePassivate and PostActivate noti?cations.
                  ...
                  The one exception is that containers are not required to reset the value of transient ?elds during activation[11]. Declaring the session bean?s ?elds as transient is, in general, discouraged.

                  In contrary to spec, we are providing a mechanism to help out a bean provider: transient re-injection. Somewhere along the line this has broken down, either TCK or injection refactoring. If we want it fixed we should build it back in, but as a seperate functionality, not hack it into the injection framework.

                  XPCs, SFSB refs and that kind of stuff is all covered in 4.2.1 and is container (/ our) responsibility, those work fine.