Are transient dependencies re-injected after it awakes from passivation?

[cayhorstmann]

I am using Weld in GlassFish and, like everyone else, am running into the error "Managed bean declaring a passivating scope must be passivation capable." Section 6.6.1 of the CDI spec says "A managed bean is passivation capable if and only if the bean class is serializable and all interceptors and decorators of the bean are serializable."

Fair enough, so I make my bean serializable.

Of course, in every one of my examples, I have a dependency to a non-serializable field:

- A stateless session bean (JSF+CDI+SLSB)
- An entity manager factory and a UserTransaction (JSF+CDI+JPA)
- A data source (JSF+CDI+JDBC)

So, I make the field transient, and it all works fine. Until, I suppose, my bean is being passivated and reactivated. Will transient fields be re-injected? The spec seemed to be silent on this issue; maybe this is dealt with elsewhere in the EJB spec?

I sure hope so, because otherwise I can't use JSF+CDI+JDBC or JSF+CDI+JPA or JSF+CDI+SLSB, which really would be a big limitation. The original Seam usecase (JSF+CDI+SFSB) does work, of course, because all SFSB are passivatable.

Thanks,

Cay

[gavin.king]

According to the spec, all stateless session beans, resources (including EntityManagerFactory and DataSource), and the UserTransaction are passivation capable dependencies, so you do not need to declare the injected fields transient.

This is a bug. I believe it is a bug in Weld that has already been fixed.

[cayhorstmann]

Thanks! Reading through 6.6.2, I now see that I am indeed assured that all SLSB and resources are going to be restored.

But I am still confused about transient. Since 6.6.1 says that my managed bean must be serializable, I must declare it so, and I can't very well lie about those dependencies. They aren't serializable, so it seems only proper to declare them as transient. I don't mind doing that--I just don't understand why you say it's not necessary. Does the app server not actually serialize the object when it passivates it?

[gavin.king]

They aren't serializable, so it seems only proper to declare them as transient.

The actual underlying resource may not be serializable by the proxified reference to it is. You should not declare the field transient.

Does the app server not actually serialize the object when it passivates it?

Exactly. It uses a proxy.

[hirowla.ian.rowlands.three.com.au]

What about Conversation objects? Are they re-injected upon activation? Some static code analysis indicates that it is a non-serializable field. Or is my code analyser just annoying?

Thanks,

Ian

[cayhorstmann]

The way I read the spec is that if CDI injects it, it owns the relationship and it will reinject it.

As for the static code analyzer, that's a good point. I see no harm in declaring the fields as transient to keep your static code analyzer happy.

[sknitelius]

There is no reinjection, after deseralization. What happens is CDI injects a serializable client proxy which is seralized along with the passivated object at least for normal scoped dependencies.

I have written a detailed blog post on their subject: https://www.knitelius.com/2016/05/18/cdi-passivation-uncovered/