Transient re-injection

[wolfc]

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.)

[bill.burke]

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

[bdecoste]

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]

[wolfc]

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.

[bill.burke]

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.

[wolfc]

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.