I have not understood following paragraph from ejb2.0 specs, section 7.4.1 :
The Bean Provider is required to ensure that the ejbPassivate method leaves the instance fields ready to be serialized by the Container. The objects that are assigned to the instance’s non-transient fields after the ejbPassivate method completes must be one of the following: • A serializable object  . • A null. • An enterprise bean’s remote interface reference, even if the stub class is not serializable. ... ... ...so on
Can somebody please explain ??? or am i too dumb to understand ! [ September 01, 2003: Message edited by: Rashmi Tambe ]
That part says that as a bean provider you are expected to replace any references to non-serializable objects with serializable "handles". A handle in this context is an object that the bean's ejbActivate() method can use to restore any non-serializable references. For example, the bean could "trade" a JDBC connection reference into a connection URL (with which the bean can make another JDBC connection).
thaks Lasse ! But tell me one thing, how would the container replace the null with serizable handle? In addition, what is the replacement for beans' home and remote interfaces? [ September 01, 2003: Message edited by: Rashmi Tambe ]
how would the container replace the null with serizable handle?
Why would the container need to replace it with anything? When the container activates the bean and realizes it doesn't have the magical serialized state object for one of the fields, it leaves it as null. Simple as that. Another approach would be for the container to replace null's with some kind of NullObject reference. Any of these internals don't affect the bean developer -- null in, null out.
In addition, what is the replacement for beans' home and remote interfaces?
The references to EJBs are already serializable (it's the container generated classes you're using, not the one(s) you typed in). How the container implements this is, again, it's own business and the developer doesn't need to care about it. Probably (if I had to make a guess) the container uses the same EJB handle mechanism as is available to you as a developer...