t:saveState + ListDataModel+ client state saving = NotSerializableException

[Dennis Byrne <de...@dbyrne.net>]

Can someone please explain the behavioral differences of the 
following two scenarios?  The JSP in both cases has  
<t:saveState value="#{bb.dataModel}"/>.

1.) No Exception if javax.faces.STATE_SAVING_METHOD=server in 
the DD .

2.) NotSerializableException if  
javax.faces.STATE_SAVING_METHOD=client is in the DD .

I can understand why the second scenario produces an 
exception - the underlying data source for the dataModel is a 
ListDataModel (which does not implement Serializable) .  And 
I am not looking for a solution because this is quickly 
solved by changing the value binding for t:saveState to #
{siteLister.dataModel.wrappedData} .  

Why does the first scenario does NOT produce an exception ?  
Dennis Byrne

Re: t:saveState + ListDataModel+ client state saving = NotSerializableException

[Werner Punz <we...@gmx.at>]

I have written a non serializing scope control based upon savestate a
while ago, it still is lingering in jsf-comp I will dump it in the
sandbox next weekend.

What I did basically was to bypass the entire serialisation within the
component entirely and to dump it into the session and having a
phase listener deal with the cleanup of the expired objects.
(Sort of what Zhong did for his backend stuff)

Werner

Martin Marinschek wrote:
> ?
> 
> the last time I looked, MyFaces serialized the session objects
> whatever the state-saving setting was, actually something we should
> make configurable. Has this changed?
> 
> regards,
> 
> Martin

Re: t:saveState + ListDataModel+ client state saving = NotSerializableException

[Martin Marinschek <ma...@gmail.com>]

?

the last time I looked, MyFaces serialized the session objects
whatever the state-saving setting was, actually something we should
make configurable. Has this changed?

regards,

Martin

On 10/5/05, Mathias Brökelmann <mb...@googlemail.com> wrote:
> The resulting state object will not be serialized if state is held on
> server. It is simply put into the session as it is.
>
> 2005/10/5, Dennis Byrne <de...@dbyrne.net>:
> > Can someone please explain the behavioral differences of the
> > following two scenarios?  The JSP in both cases has
> > <t:saveState value="#{bb.dataModel}"/>.
> >
> > 1.) No Exception if javax.faces.STATE_SAVING_METHOD=server in
> > the DD .
> >
> > 2.) NotSerializableException if
> > javax.faces.STATE_SAVING_METHOD=client is in the DD .
> >
> > I can understand why the second scenario produces an
> > exception - the underlying data source for the dataModel is a
> > ListDataModel (which does not implement Serializable) .  And
> > I am not looking for a solution because this is quickly
> > solved by changing the value binding for t:saveState to #
> > {siteLister.dataModel.wrappedData} .
> >
> > Why does the first scenario does NOT produce an exception ?
> > Dennis Byrne
> >
>
>
> --
> Mathias
>


--

http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German

Re: t:saveState + ListDataModel+ client state saving = NotSerializableException

[Mathias Brökelmann <mb...@googlemail.com>]

The resulting state object will not be serialized if state is held on
server. It is simply put into the session as it is.

2005/10/5, Dennis Byrne <de...@dbyrne.net>:
> Can someone please explain the behavioral differences of the
> following two scenarios?  The JSP in both cases has
> <t:saveState value="#{bb.dataModel}"/>.
>
> 1.) No Exception if javax.faces.STATE_SAVING_METHOD=server in
> the DD .
>
> 2.) NotSerializableException if
> javax.faces.STATE_SAVING_METHOD=client is in the DD .
>
> I can understand why the second scenario produces an
> exception - the underlying data source for the dataModel is a
> ListDataModel (which does not implement Serializable) .  And
> I am not looking for a solution because this is quickly
> solved by changing the value binding for t:saveState to #
> {siteLister.dataModel.wrappedData} .
>
> Why does the first scenario does NOT produce an exception ?
> Dennis Byrne
>


--
Mathias