Seam POJO, serializable or not ?

[gjeudy]

Hi,

I have Seam POJOs in CONVERSATION scope in my app deployed on JBAS4.2.2 and I would like to know if i'm forced to have them implement Serializable? I had the impression that was only required for SFSBs because of EJB passivation or if you run in clustered mode.

Yet if I don't implement Serializable, Seam still warns about it on startup...

My understanding is that if the container does not passivate HttpSessions then we don't need Seam POJOs to be Serializable.

What are thoughts of others on this?

Thanks!
-Guillaume

[swd847]

It depends if you want to cluster the http session or not. The app will run fine otherwise.

[gonorrhea]

The conversation scope is a managed space in the HttpSession space.  It's best to follow the recommendations and implement the java.io.Serializable marker interface when considering conversation-scoped JavaBeans.

Here's an excerpt from Seam in Action:

Let’s consider another difficult scenario that’s cleared up thanks to the dynamic
nature of Seam’s DI: mixing nonserializable objects with serializable objects (a serializable
object is an instance of any class that implements java.io.Serializable). If a
nonserializable object is injected into the property of a serializable session-scoped
object, and that property isn’t cleared prior to session passivation, the session storage
mechanism will get tripped up by the nonserializable data. You could, of course, mark
the field as transient so that the value would be automatically cleared, hence allowing
the session to properly passivate. However, the real problem is that once the session
is restored, the transient field remains null, acting as a land mine in the form of a
NullPointerException that may be triggered by an unsuspecting block of code.

My understanding is that if the container does not passivate HttpSessions then we don't need Seam POJOs to be Serializable.

why would you want a container or configure a container to not passivate SFSB's to disk?  Each client requires its own SFSB, so it's in your best interest to have the container passivate SFSBs based on an algorithm like LRU or MRU, etc.  This is one of the advantages of using a JEE app server like JBoss, WebLogic, etc.

The bottom line is if you're sure you are not going to be using any EJBs at all, then perhaps you don't need to implement Serializable interface.  If you're going to be using JavaBeans and EJBs, then follow the rules...

[gonorrhea]

Stuart Douglas wrote on Apr 04, 2009 00:44:


It depends if you want to cluster the http session or not. The app will run fine otherwise.

this is a good way to summarize it.  state replication requires shuttling data across the wire (over your LAN/WAN) so your classes must implement Serializable otherwise state can't be replicated from node to node.

most production systems will require some sort of clustering (say a 2 node horz cluster) and thus you should follow the rules if you have non-functional requirements like fault tolerance, performance, failover, scalability, etc.

[gjeudy]

Right, I understand the rules for SFSBs but i'm not using them. The rational behind making Seam POJOs Serializable is pretty clear to me now.

Thanks Guys!