> Normally objects in the JSF component tree (ie "the current view") are
> never stored in the http session. Instead, the JSF implementation takes
Hm, since this is the myfaces mailing list, I'd like to point out that
Trinidad has a configuration parameter
org.apache.myfaces.trinidad.CACHE_VIEW_ROOT
which defaults to true.
My understanding is that if CACHE_VIEW_ROOT, then the complete tree of
components is directly (without converting to byte[], serialization or such)
in the session.
(See http://myfaces.apache.org/trinidad/devguide/configuration.html )
Simon Kitching wrote:
On Sat, 2008-09-13 at 17:53 +0200, mehdi sidhoum wrote:
Hi list !
I have the following question, which I still haven't answered : Which
problems can we encounter if a UI class component implements the
java.io.Serializable ? Is it permitted to serialize the UI classes ?
After reading the Java Servlet Specification 2.4
<http://java.sun.com/products/servlet/download.html#specs> I have
noticed that Serialization of /HttpSession object /is depending of the
server application container, the call methods readObject () and
writeObject () is not guaranteed (in the case of a custom serialization).
What do you think about the custom Serialization (I means class
implements Externalizable interface) in jsf applications ?
Normally objects in the JSF component tree (ie "the current view") are
never stored in the http session. Instead, the JSF implementation takes
responsibility for mapping the current JSF component tree into an array
of bytes. The array is then either stored in the http session (for
server-side-state-saving) or is stored in a hidden field of a form (for
client-side-state-saving).
If you write your own subclass of the jsf UIComponent class, then it
should really implement the jsf StateHolder interface, and not
java.io.Serializable. The JSF implementation will check each component
to see if it implements StateHolder, and if so then it calls the methods
on that interface. I think that if a component does *not* implement
StateHolder then JSF implementations do fall back to invoking
java.io.Serializable methods instead. But StateHolder is a better thing
to use.
If you use component binding (ecch) to a bean that is in the session,
and store a reference to the component in a non-transient field then the
*entire* component tree will end up being serialized in the session,
because the "bound" component has references to its parent and children.
This is a *really bad thing to do* for obvious reasons. Therefore
(a) avoid component bindings where possible
(b) use request-scoped beans if you have to use bindings
(c) if you *really* have to have a binding to a session-scoped bean,
then mark the reference as transient.
So in short:
(1) implement the StateHolder interface on your custom uicomponent
classes
(2) do NOT implement java.io.Serializable, as it will never be used
(provided you've properly coded your app to follow the above
recommendations)
And in future, please ask this sort of question on the user list. Unless
you are proposing a patch to the core implementation, the user list is
the correct place. All the developers subscribe to the user list too, so
there is no benefit in posting here.
Regards,
Simon
