You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Martin Marinschek <ma...@gmail.com> on 2005/10/18 17:23:22 UTC
Super!
Mathias,
wow - you have solved the server side state saving problem we have had for ages?
That will make some users very, very happy!
Thanks from the whole team, great news indeed.
Do you want to give us (on the dev list) a short wrapup on how you
solved things? Did you keep close to the RI or did you implement a
different solution?
regards,
Martin
Re: Super!
Posted by Mario Ivankovits <ma...@ops.co.at>.
Mario Ivankovits wrote:
> http://issues.apache.org/jira/browse/MYFACES-516
Oh, and I tried to survive the messages too.
---
Mario
Re: Super!
Posted by Mario Ivankovits <ma...@ops.co.at>.
Mathias Brökelmann wrote:
> Redirection is not handled. Neither by client nor by server side state saving.
>
Its not a question of client or server side state saving.
If you do NOT use redirect you are still in the same request and thus
have access to beans modified during this request.
If you put "<redirect />" in your navigation rules (e.g. to have correct
urls) those beans are discarded. So this little option has a big impact
to your application flow.
This is what my patch tries to address, and IMHO it should be possible
to do the same with your sequence number (I have done it the same way).
--
Mario
Re: Super!
Posted by Mathias Brökelmann <mb...@googlemail.com>.
Redirection is not handled. Neither by client nor by server side state saving.
2005/10/18, Mario Ivankovits <ma...@ops.co.at>:
> Mathias Brökelmann wrote:
> > If server side state is uses the serialized view is now really
> > serialized (this was not the case before) into the session by using
> > the viewid and a sequence number.
> May I ask if you also add this sequence number to the redirect url if
> one uses <redirect navigation style.
>
> Please see
> http://issues.apache.org/jira/browse/MYFACES-516
> where I already proposed such a patch.
> Now you reimplemented the sequence stuff it should be possible to use it
> for redirect too.
>
> ---
> Mario
>
>
--
Mathias
Re: Super!
Posted by Mario Ivankovits <ma...@ops.co.at>.
Mathias Brökelmann wrote:
> If server side state is uses the serialized view is now really
> serialized (this was not the case before) into the session by using
> the viewid and a sequence number.
May I ask if you also add this sequence number to the redirect url if
one uses <redirect navigation style.
Please see
http://issues.apache.org/jira/browse/MYFACES-516
where I already proposed such a patch.
Now you reimplemented the sequence stuff it should be possible to use it
for redirect too.
---
Mario
Re: Super!
Posted by Werner Punz <we...@gmx.at>.
Martin Marinschek wrote:
> Sounds very good indeed!
>
> Mathias - absolutely professional as always ;)
>
> Werner, you did have a need for such a thing as well, right?
>
Yes I had a huge need for that.. ;-)
> So you might check this out a bit?
>
I will ASAP... btw... I have good news, if you can contact me privately.
Werner
Re: Super!
Posted by Martin Marinschek <ma...@gmail.com>.
Sounds very good indeed!
Mathias - absolutely professional as always ;)
Werner, you did have a need for such a thing as well, right?
So you might check this out a bit?
regards,
Martin
On 10/18/05, Mathias Brökelmann <mb...@googlemail.com> wrote:
> Well, I have not taken a look into the ri for this issue. So I can not
> say if it is solved like the ri.
>
> This is what I have done:
>
> If server side state is uses the serialized view is now really
> serialized (this was not the case before) into the session by using
> the viewid and a sequence number. The sequence number will be rendered
> into the response (either as a hidden input field if used in forms or
> as a param in a url). This sequence could also be used for other
> things since it is increased by every request. The last sequence used
> is also stored into the session.
>
> To restore the response the viewid and the sequenceid from the request
> is used to determine the serialized view. The last 15 (currently fixed
> number) views will be saved into the session. I´ve utilized a
> ReferenceMap which uses SoftReference instances for the views after
> the 15th. So if the garbage collector doesn´t collect these values
> they are still available.
>
> I´ve done some testing so it seams to work. If anyone (maybe you
> Marting ;)) finds the time to make some more tests I would be very
> happy.
>
> Best Regards,
>
> Mathias
>
> 2005/10/18, Martin Marinschek <ma...@gmail.com>:
> > Mathias,
> >
> > wow - you have solved the server side state saving problem we have had for ages?
> >
> > That will make some users very, very happy!
> >
> > Thanks from the whole team, great news indeed.
> >
> > Do you want to give us (on the dev list) a short wrapup on how you
> > solved things? Did you keep close to the RI or did you implement a
> > different solution?
> >
> > regards,
> >
> > Martin
> >
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German
Re: Super!
Posted by "ir. ing. Jan Dockx" <ja...@mac.com>.
Sensible.
On 19 Oct 2005, at 9:51, Mathias Brökelmann wrote:
> Its only in the main trunk. Since it is not fully tested and the next
> maintenance release is quite close I´ve not commited it into the 1.1.1
> banch.
>
> 2005/10/19, ir. ing. Jan Dockx <ja...@mac.com>:
>> About the branches: is this only in the main trunk, or also in the
>> 1.1.1 trunk (and thus will be in the RC3)?
>>
>> On 18 Oct 2005, at 22:06, Adam Winer wrote:
>>
>>> This sounds roughly like the implementation of server-side
>>> state saving in the JSF 1.2 RI, as well as what's done in ADF Faces,
>>> though not exactly, 'cause there's differences in the details
>>> (neither,
>>> for instance, supports putting sequence numbers into URLs, just
>>> hidden fields).
>>>
>>> What exactly do you mean by "the serialized view is now really
>>> serialized (this was not the case before)"? Before, server-side
>>> state saving (at least in 1.1 RI) was just stashing the UIViewRoot,
>>> which dies for a bunch of reasons. I'm gonna guess that
>>> you grab the SerializedView object with StateManager.saveState(),
>>> and then save off its two components.
>>>
>>> Getting per-request state to survive <redirect/>, like Mario's
>>> proposing,
>>> is a separate issue, as you say.
>>>
>>> -- Adam
>>>
>>>
>>> On 10/18/05, Mathias Brökelmann <mb...@googlemail.com> wrote:
>>>> Well, I have not taken a look into the ri for this issue. So I can
>>>> not
>>>> say if it is solved like the ri.
>>>>
>>>> This is what I have done:
>>>>
>>>> If server side state is uses the serialized view is now really
>>>> serialized (this was not the case before) into the session by using
>>>> the viewid and a sequence number. The sequence number will be
>>>> rendered
>>>> into the response (either as a hidden input field if used in forms
>>>> or
>>>> as a param in a url). This sequence could also be used for other
>>>> things since it is increased by every request. The last sequence
>>>> used
>>>> is also stored into the session.
>>>>
>>>> To restore the response the viewid and the sequenceid from the
>>>> request
>>>> is used to determine the serialized view. The last 15 (currently
>>>> fixed
>>>> number) views will be saved into the session. I´ve utilized a
>>>> ReferenceMap which uses SoftReference instances for the views after
>>>> the 15th. So if the garbage collector doesn´t collect these values
>>>> they are still available.
>>>>
>>>> I´ve done some testing so it seams to work. If anyone (maybe you
>>>> Marting ;)) finds the time to make some more tests I would be very
>>>> happy.
>>>>
>>>> Best Regards,
>>>>
>>>> Mathias
>>>>
>>>> 2005/10/18, Martin Marinschek <ma...@gmail.com>:
>>>>> Mathias,
>>>>>
>>>>> wow - you have solved the server side state saving problem we have
>>>>> had for ages?
>>>>>
>>>>> That will make some users very, very happy!
>>>>>
>>>>> Thanks from the whole team, great news indeed.
>>>>>
>>>>> Do you want to give us (on the dev list) a short wrapup on how you
>>>>> solved things? Did you keep close to the RI or did you implement a
>>>>> different solution?
>>>>>
>>>>> regards,
>>>>>
>>>>> Martin
>>>>>
>>>>
>>>
>>>
>> Met vriendelijke groeten,
>>
>> Jan Dockx
>>
>> PeopleWare NV - Head Office
>> Cdt.Weynsstraat 85
>> B-2660 Hoboken
>> Tel: +32 3 448.33.38
>> Fax: +32 3 448.32.66
>>
>> PeopleWare NV - Branch Office Geel
>> Kleinhoefstraat 5
>> B-2440 Geel
>> Tel: +32 14 57.00.90
>> Fax: +32 14 58.13.25
>>
>> http://www.peopleware.be/
>> http://www.mobileware.be/
>>
>>
>>
>
>
> --
> Mathias
>
>
Met vriendelijke groeten,
Jan Dockx
PeopleWare NV - Head Office
Cdt.Weynsstraat 85
B-2660 Hoboken
Tel: +32 3 448.33.38
Fax: +32 3 448.32.66
PeopleWare NV - Branch Office Geel
Kleinhoefstraat 5
B-2440 Geel
Tel: +32 14 57.00.90
Fax: +32 14 58.13.25
http://www.peopleware.be/
http://www.mobileware.be/
Re: Super!
Posted by Mathias Brökelmann <mb...@googlemail.com>.
Its only in the main trunk. Since it is not fully tested and the next
maintenance release is quite close I´ve not commited it into the 1.1.1
banch.
2005/10/19, ir. ing. Jan Dockx <ja...@mac.com>:
> About the branches: is this only in the main trunk, or also in the
> 1.1.1 trunk (and thus will be in the RC3)?
>
> On 18 Oct 2005, at 22:06, Adam Winer wrote:
>
> > This sounds roughly like the implementation of server-side
> > state saving in the JSF 1.2 RI, as well as what's done in ADF Faces,
> > though not exactly, 'cause there's differences in the details (neither,
> > for instance, supports putting sequence numbers into URLs, just
> > hidden fields).
> >
> > What exactly do you mean by "the serialized view is now really
> > serialized (this was not the case before)"? Before, server-side
> > state saving (at least in 1.1 RI) was just stashing the UIViewRoot,
> > which dies for a bunch of reasons. I'm gonna guess that
> > you grab the SerializedView object with StateManager.saveState(),
> > and then save off its two components.
> >
> > Getting per-request state to survive <redirect/>, like Mario's
> > proposing,
> > is a separate issue, as you say.
> >
> > -- Adam
> >
> >
> > On 10/18/05, Mathias Brökelmann <mb...@googlemail.com> wrote:
> >> Well, I have not taken a look into the ri for this issue. So I can not
> >> say if it is solved like the ri.
> >>
> >> This is what I have done:
> >>
> >> If server side state is uses the serialized view is now really
> >> serialized (this was not the case before) into the session by using
> >> the viewid and a sequence number. The sequence number will be rendered
> >> into the response (either as a hidden input field if used in forms or
> >> as a param in a url). This sequence could also be used for other
> >> things since it is increased by every request. The last sequence used
> >> is also stored into the session.
> >>
> >> To restore the response the viewid and the sequenceid from the request
> >> is used to determine the serialized view. The last 15 (currently fixed
> >> number) views will be saved into the session. I´ve utilized a
> >> ReferenceMap which uses SoftReference instances for the views after
> >> the 15th. So if the garbage collector doesn´t collect these values
> >> they are still available.
> >>
> >> I´ve done some testing so it seams to work. If anyone (maybe you
> >> Marting ;)) finds the time to make some more tests I would be very
> >> happy.
> >>
> >> Best Regards,
> >>
> >> Mathias
> >>
> >> 2005/10/18, Martin Marinschek <ma...@gmail.com>:
> >>> Mathias,
> >>>
> >>> wow - you have solved the server side state saving problem we have
> >>> had for ages?
> >>>
> >>> That will make some users very, very happy!
> >>>
> >>> Thanks from the whole team, great news indeed.
> >>>
> >>> Do you want to give us (on the dev list) a short wrapup on how you
> >>> solved things? Did you keep close to the RI or did you implement a
> >>> different solution?
> >>>
> >>> regards,
> >>>
> >>> Martin
> >>>
> >>
> >
> >
> Met vriendelijke groeten,
>
> Jan Dockx
>
> PeopleWare NV - Head Office
> Cdt.Weynsstraat 85
> B-2660 Hoboken
> Tel: +32 3 448.33.38
> Fax: +32 3 448.32.66
>
> PeopleWare NV - Branch Office Geel
> Kleinhoefstraat 5
> B-2440 Geel
> Tel: +32 14 57.00.90
> Fax: +32 14 58.13.25
>
> http://www.peopleware.be/
> http://www.mobileware.be/
>
>
>
--
Mathias
Re: Super!
Posted by "ir. ing. Jan Dockx" <ja...@mac.com>.
About the branches: is this only in the main trunk, or also in the
1.1.1 trunk (and thus will be in the RC3)?
On 18 Oct 2005, at 22:06, Adam Winer wrote:
> This sounds roughly like the implementation of server-side
> state saving in the JSF 1.2 RI, as well as what's done in ADF Faces,
> though not exactly, 'cause there's differences in the details (neither,
> for instance, supports putting sequence numbers into URLs, just
> hidden fields).
>
> What exactly do you mean by "the serialized view is now really
> serialized (this was not the case before)"? Before, server-side
> state saving (at least in 1.1 RI) was just stashing the UIViewRoot,
> which dies for a bunch of reasons. I'm gonna guess that
> you grab the SerializedView object with StateManager.saveState(),
> and then save off its two components.
>
> Getting per-request state to survive <redirect/>, like Mario's
> proposing,
> is a separate issue, as you say.
>
> -- Adam
>
>
> On 10/18/05, Mathias Brökelmann <mb...@googlemail.com> wrote:
>> Well, I have not taken a look into the ri for this issue. So I can not
>> say if it is solved like the ri.
>>
>> This is what I have done:
>>
>> If server side state is uses the serialized view is now really
>> serialized (this was not the case before) into the session by using
>> the viewid and a sequence number. The sequence number will be rendered
>> into the response (either as a hidden input field if used in forms or
>> as a param in a url). This sequence could also be used for other
>> things since it is increased by every request. The last sequence used
>> is also stored into the session.
>>
>> To restore the response the viewid and the sequenceid from the request
>> is used to determine the serialized view. The last 15 (currently fixed
>> number) views will be saved into the session. I´ve utilized a
>> ReferenceMap which uses SoftReference instances for the views after
>> the 15th. So if the garbage collector doesn´t collect these values
>> they are still available.
>>
>> I´ve done some testing so it seams to work. If anyone (maybe you
>> Marting ;)) finds the time to make some more tests I would be very
>> happy.
>>
>> Best Regards,
>>
>> Mathias
>>
>> 2005/10/18, Martin Marinschek <ma...@gmail.com>:
>>> Mathias,
>>>
>>> wow - you have solved the server side state saving problem we have
>>> had for ages?
>>>
>>> That will make some users very, very happy!
>>>
>>> Thanks from the whole team, great news indeed.
>>>
>>> Do you want to give us (on the dev list) a short wrapup on how you
>>> solved things? Did you keep close to the RI or did you implement a
>>> different solution?
>>>
>>> regards,
>>>
>>> Martin
>>>
>>
>
>
Met vriendelijke groeten,
Jan Dockx
PeopleWare NV - Head Office
Cdt.Weynsstraat 85
B-2660 Hoboken
Tel: +32 3 448.33.38
Fax: +32 3 448.32.66
PeopleWare NV - Branch Office Geel
Kleinhoefstraat 5
B-2440 Geel
Tel: +32 14 57.00.90
Fax: +32 14 58.13.25
http://www.peopleware.be/
http://www.mobileware.be/
Re: Super!
Posted by Mathias Brökelmann <mb...@googlemail.com>.
I´ve added two context parameters:
org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION
defines the number of the latest views stored in the session with a
default of 20 (like RI)
org.apache.myfaces.SERIALIZE_STATE_IN_SESSION
if true (default) the state will be serialized to a byte array,
otherwise it will not be serialized.
IMO the last param should be used with care if it is true for
development time and false for deployment. The component t:savestate
may save the state of any complex statefull bean which may hold a
state too. So this state will get shared between the views if it is
not serialized. So expect a different behavior if switching this flag
on a production system.
2005/10/20, Adam Winer <aw...@gmail.com>:
> Ah, so you don't save the objects directly, you save the byte streams?
>
> That's excellent for development - it's a pain figuring out down the road
> that one object way down deep isn't serializable, and only when you try
> clustering right before going production :) - but seems like an unnecessary
> performance hit at deployment time. Perhaps a flag to switch between the
> two?
>
> -- Adam
>
>
>
>
> On 10/19/05, Mathias Brökelmann <mb...@googlemail.com> wrote:
> > You are right the two objects in SerailizedView are serialized and put
> > into the session.
> >
> > The instances of the server side state where not serialized before.
> > This doesn´t affect the component instances since they are only
> > referenced by class name in the state but it could have an effect on
> > the state of the components. Some components may have statefull
> > objects in their state (t:savestate for instance)
> >
> > The next thing is that clustering or a restart of the container is now
> > better supported because the user will see a NotSerializeableException
> > immediatly if a value of the state is not serializable.
> >
> > 2005/10/18, Adam Winer <aw...@gmail.com>:
> > > What exactly do you mean by "the serialized view is now really
> > > serialized (this was not the case before)"? Before, server-side
> > > state saving (at least in 1.1 RI) was just stashing the UIViewRoot,
> > > which dies for a bunch of reasons. I'm gonna guess that
> > > you grab the SerializedView object with StateManager.saveState(),
> > > and then save off its two components.
> >
> >
> > --
> > Mathias
> >
>
>
--
Mathias
Re: Super!
Posted by Mathias Brökelmann <mb...@googlemail.com>.
IMO saving the state like jsf does is a very nice solution for this
problem. I like it because it perfectly follows the OO paradigms and
is easy to implement. I use it for our applications too. Whenever I
have to handle table data where some fields needs to maintain a state
for each row it is possible to hold the state for each field for a row
through saveState/restoreState. I also use it for saving/restoring
user preferences.
Do you use an other solution to store/restore the state of components?
2005/10/20, Simon Kitching <sk...@obsidium.com>:
> I'm still on the JSF learning curve, but I believe we're talking here
> about saving the UIComponent tree state, and that that is done via a
> custom approach in JSF.
>
> Firstly the JSF framework saves the classnames of the UIComponent object
> tree, so that it can build an identical tree (but of new UIComponent
> instances) when it needs to.
>
> Then each UIComponent object in the tree has its "saveState" method
> called, which is expected to return an object array containing its
> state. The UIComponent doesn't use java serialization; components with
> no children typically just store the primitive values of its member
> fields into an object array. Note that saveState can't use normal
> serialization because the "component tree" has already been rebuilt by
> the framework and that the return value of saveState is used to
> *repopulate a particular UIComponent instance* (the one restoreState is
> called on) rather than creating a UIComponent tree as deserialisation
> would do.
>
> I don't know why this custom approach was used.
>
> If I'm on the wrong track, please let me know.
>
> Regards,
>
> Simon
>
> Adam Winer wrote:
> > Ah, so you don't save the objects directly, you save the byte streams?
> >
> > That's excellent for development - it's a pain figuring out down the
> > road that one object way down deep isn't serializable, and only when you
> > try clustering right before going production :) - but seems like an
> > unnecessary performance hit at deployment time. Perhaps a flag to
> > switch between the two?
> >
> > -- Adam
> >
> >
> >
> > On 10/19/05, *Mathias Brökelmann* <mbroekelmann@googlemail.com
> > <ma...@googlemail.com>> wrote:
> >
> > You are right the two objects in SerailizedView are serialized and put
> > into the session.
> >
> > The instances of the server side state where not serialized before.
> > This doesn´t affect the component instances since they are only
> > referenced by class name in the state but it could have an effect on
> > the state of the components. Some components may have statefull
> > objects in their state (t:savestate for instance)
> >
> > The next thing is that clustering or a restart of the container is now
> > better supported because the user will see a NotSerializeableException
> > immediatly if a value of the state is not serializable.
> >
> > 2005/10/18, Adam Winer <awiner@gmail.com <ma...@gmail.com>>:
> > > What exactly do you mean by "the serialized view is now really
> > > serialized (this was not the case before)"? Before, server-side
> > > state saving (at least in 1.1 RI) was just stashing the UIViewRoot,
> > > which dies for a bunch of reasons. I'm gonna guess that
> > > you grab the SerializedView object with StateManager.saveState(),
> > > and then save off its two components.
> >
> >
> > --
> > Mathias
> >
> >
>
>
--
Mathias
Re: Super!
Posted by Werner Punz <we...@gmx.at>.
Simon Kitching wrote:
> I'm still on the JSF learning curve, but I believe we're talking here
> about saving the UIComponent tree state, and that that is done via a
> custom approach in JSF.
>
> Firstly the JSF framework saves the classnames of the UIComponent object
> tree, so that it can build an identical tree (but of new UIComponent
> instances) when it needs to.
>
> Then each UIComponent object in the tree has its "saveState" method
> called, which is expected to return an object array containing its
> state. The UIComponent doesn't use java serialization; components with
> no children typically just store the primitive values of its member
> fields into an object array. Note that saveState can't use normal
> serialization because the "component tree" has already been rebuilt by
> the framework and that the return value of saveState is used to
> *repopulate a particular UIComponent instance* (the one restoreState is
> called on) rather than creating a UIComponent tree as deserialisation
> would do.
>
> I don't know why this custom approach was used.
>
> If I'm on the wrong track, please let me know.
>
Probably to reduce the amount of data, every component only stores the
data it really has to, the problem of this approach is a slightly
performance hit, especially if you are in a cluster environment, because
the serialisation is basically done twice, first
from the component tree into the session and then from the session to
whatever is used for clustering.
But given the speed I can see from a bunch of running JSF apps I have
this performance hit is pretty neglectable.
As usual the biggest bottleneck always is db access.
Re: Super!
Posted by Simon Kitching <sk...@obsidium.com>.
I'm still on the JSF learning curve, but I believe we're talking here
about saving the UIComponent tree state, and that that is done via a
custom approach in JSF.
Firstly the JSF framework saves the classnames of the UIComponent object
tree, so that it can build an identical tree (but of new UIComponent
instances) when it needs to.
Then each UIComponent object in the tree has its "saveState" method
called, which is expected to return an object array containing its
state. The UIComponent doesn't use java serialization; components with
no children typically just store the primitive values of its member
fields into an object array. Note that saveState can't use normal
serialization because the "component tree" has already been rebuilt by
the framework and that the return value of saveState is used to
*repopulate a particular UIComponent instance* (the one restoreState is
called on) rather than creating a UIComponent tree as deserialisation
would do.
I don't know why this custom approach was used.
If I'm on the wrong track, please let me know.
Regards,
Simon
Adam Winer wrote:
> Ah, so you don't save the objects directly, you save the byte streams?
>
> That's excellent for development - it's a pain figuring out down the
> road that one object way down deep isn't serializable, and only when you
> try clustering right before going production :) - but seems like an
> unnecessary performance hit at deployment time. Perhaps a flag to
> switch between the two?
>
> -- Adam
>
>
>
> On 10/19/05, *Mathias Brökelmann* <mbroekelmann@googlemail.com
> <ma...@googlemail.com>> wrote:
>
> You are right the two objects in SerailizedView are serialized and put
> into the session.
>
> The instances of the server side state where not serialized before.
> This doesn´t affect the component instances since they are only
> referenced by class name in the state but it could have an effect on
> the state of the components. Some components may have statefull
> objects in their state (t:savestate for instance)
>
> The next thing is that clustering or a restart of the container is now
> better supported because the user will see a NotSerializeableException
> immediatly if a value of the state is not serializable.
>
> 2005/10/18, Adam Winer <awiner@gmail.com <ma...@gmail.com>>:
> > What exactly do you mean by "the serialized view is now really
> > serialized (this was not the case before)"? Before, server-side
> > state saving (at least in 1.1 RI) was just stashing the UIViewRoot,
> > which dies for a bunch of reasons. I'm gonna guess that
> > you grab the SerializedView object with StateManager.saveState(),
> > and then save off its two components.
>
>
> --
> Mathias
>
>
Re: Super!
Posted by Adam Winer <aw...@gmail.com>.
Ah, so you don't save the objects directly, you save the byte streams?
That's excellent for development - it's a pain figuring out down the road
that one object way down deep isn't serializable, and only when you try
clustering right before going production :) - but seems like an unnecessary
performance hit at deployment time. Perhaps a flag to switch between the
two?
-- Adam
On 10/19/05, Mathias Brökelmann <mb...@googlemail.com> wrote:
>
> You are right the two objects in SerailizedView are serialized and put
> into the session.
>
> The instances of the server side state where not serialized before.
> This doesn´t affect the component instances since they are only
> referenced by class name in the state but it could have an effect on
> the state of the components. Some components may have statefull
> objects in their state (t:savestate for instance)
>
> The next thing is that clustering or a restart of the container is now
> better supported because the user will see a NotSerializeableException
> immediatly if a value of the state is not serializable.
>
> 2005/10/18, Adam Winer <aw...@gmail.com>:
> > What exactly do you mean by "the serialized view is now really
> > serialized (this was not the case before)"? Before, server-side
> > state saving (at least in 1.1 RI) was just stashing the UIViewRoot,
> > which dies for a bunch of reasons. I'm gonna guess that
> > you grab the SerializedView object with StateManager.saveState(),
> > and then save off its two components.
>
>
> --
> Mathias
>
Re: Super!
Posted by Mathias Brökelmann <mb...@googlemail.com>.
You are right the two objects in SerailizedView are serialized and put
into the session.
The instances of the server side state where not serialized before.
This doesn´t affect the component instances since they are only
referenced by class name in the state but it could have an effect on
the state of the components. Some components may have statefull
objects in their state (t:savestate for instance)
The next thing is that clustering or a restart of the container is now
better supported because the user will see a NotSerializeableException
immediatly if a value of the state is not serializable.
2005/10/18, Adam Winer <aw...@gmail.com>:
> What exactly do you mean by "the serialized view is now really
> serialized (this was not the case before)"? Before, server-side
> state saving (at least in 1.1 RI) was just stashing the UIViewRoot,
> which dies for a bunch of reasons. I'm gonna guess that
> you grab the SerializedView object with StateManager.saveState(),
> and then save off its two components.
--
Mathias
Re: Super!
Posted by Martin Marinschek <ma...@gmail.com>.
That is my only feature enhancement wish as well ;)
regards,
Martin
On 10/19/05, sharath reddy <sh...@yahoo.com> wrote:
>
> Just FYI...
>
> I took a look at the RI Implemention. The user is
> allowed to specify as a ServletContextInitParameter
> the maximum number of logical views to be saved in
> session. If no value is specified, then the default
> value is used.
>
> --- Adam Winer <aw...@gmail.com> wrote:
>
> > This sounds roughly like the implementation of
> > server-side
> > state saving in the JSF 1.2 RI, as well as what's
> > done in ADF Faces,
> > though not exactly, 'cause there's differences in
> > the details (neither,
> > for instance, supports putting sequence numbers into
> > URLs, just
> > hidden fields).
> >
> > What exactly do you mean by "the serialized view is
> > now really
> > serialized (this was not the case before)"? Before,
> > server-side
> > state saving (at least in 1.1 RI) was just stashing
> > the UIViewRoot,
> > which dies for a bunch of reasons. I'm gonna guess
> > that
> > you grab the SerializedView object with
> > StateManager.saveState(),
> > and then save off its two components.
> >
> > Getting per-request state to survive <redirect/>,
> > like Mario's proposing,
> > is a separate issue, as you say.
> >
> > -- Adam
> >
> >
> > On 10/18/05, Mathias Brökelmann
> > <mb...@googlemail.com> wrote:
> > > Well, I have not taken a look into the ri for this
> > issue. So I can not
> > > say if it is solved like the ri.
> > >
> > > This is what I have done:
> > >
> > > If server side state is uses the serialized view
> > is now really
> > > serialized (this was not the case before) into the
> > session by using
> > > the viewid and a sequence number. The sequence
> > number will be rendered
> > > into the response (either as a hidden input field
> > if used in forms or
> > > as a param in a url). This sequence could also be
> > used for other
> > > things since it is increased by every request. The
> > last sequence used
> > > is also stored into the session.
> > >
> > > To restore the response the viewid and the
> > sequenceid from the request
> > > is used to determine the serialized view. The last
> > 15 (currently fixed
> > > number) views will be saved into the session. I´ve
> > utilized a
> > > ReferenceMap which uses SoftReference instances
> > for the views after
> > > the 15th. So if the garbage collector doesn´t
> > collect these values
> > > they are still available.
> > >
> > > I´ve done some testing so it seams to work. If
> > anyone (maybe you
> > > Marting ;)) finds the time to make some more tests
> > I would be very
> > > happy.
> > >
> > > Best Regards,
> > >
> > > Mathias
> > >
> > > 2005/10/18, Martin Marinschek
> > <ma...@gmail.com>:
> > > > Mathias,
> > > >
> > > > wow - you have solved the server side state
> > saving problem we have had for ages?
> > > >
> > > > That will make some users very, very happy!
> > > >
> > > > Thanks from the whole team, great news indeed.
> > > >
> > > > Do you want to give us (on the dev list) a short
> > wrapup on how you
> > > > solved things? Did you keep close to the RI or
> > did you implement a
> > > > different solution?
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > >
> >
>
>
>
>
> __________________________________
> Yahoo! Music Unlimited
> Access over 1 million songs. Try it free.
> http://music.yahoo.com/unlimited/
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German
Re: Super!
Posted by sharath reddy <sh...@yahoo.com>.
Just FYI...
I took a look at the RI Implemention. The user is
allowed to specify as a ServletContextInitParameter
the maximum number of logical views to be saved in
session. If no value is specified, then the default
value is used.
--- Adam Winer <aw...@gmail.com> wrote:
> This sounds roughly like the implementation of
> server-side
> state saving in the JSF 1.2 RI, as well as what's
> done in ADF Faces,
> though not exactly, 'cause there's differences in
> the details (neither,
> for instance, supports putting sequence numbers into
> URLs, just
> hidden fields).
>
> What exactly do you mean by "the serialized view is
> now really
> serialized (this was not the case before)"? Before,
> server-side
> state saving (at least in 1.1 RI) was just stashing
> the UIViewRoot,
> which dies for a bunch of reasons. I'm gonna guess
> that
> you grab the SerializedView object with
> StateManager.saveState(),
> and then save off its two components.
>
> Getting per-request state to survive <redirect/>,
> like Mario's proposing,
> is a separate issue, as you say.
>
> -- Adam
>
>
> On 10/18/05, Mathias Brökelmann
> <mb...@googlemail.com> wrote:
> > Well, I have not taken a look into the ri for this
> issue. So I can not
> > say if it is solved like the ri.
> >
> > This is what I have done:
> >
> > If server side state is uses the serialized view
> is now really
> > serialized (this was not the case before) into the
> session by using
> > the viewid and a sequence number. The sequence
> number will be rendered
> > into the response (either as a hidden input field
> if used in forms or
> > as a param in a url). This sequence could also be
> used for other
> > things since it is increased by every request. The
> last sequence used
> > is also stored into the session.
> >
> > To restore the response the viewid and the
> sequenceid from the request
> > is used to determine the serialized view. The last
> 15 (currently fixed
> > number) views will be saved into the session. I´ve
> utilized a
> > ReferenceMap which uses SoftReference instances
> for the views after
> > the 15th. So if the garbage collector doesn´t
> collect these values
> > they are still available.
> >
> > I´ve done some testing so it seams to work. If
> anyone (maybe you
> > Marting ;)) finds the time to make some more tests
> I would be very
> > happy.
> >
> > Best Regards,
> >
> > Mathias
> >
> > 2005/10/18, Martin Marinschek
> <ma...@gmail.com>:
> > > Mathias,
> > >
> > > wow - you have solved the server side state
> saving problem we have had for ages?
> > >
> > > That will make some users very, very happy!
> > >
> > > Thanks from the whole team, great news indeed.
> > >
> > > Do you want to give us (on the dev list) a short
> wrapup on how you
> > > solved things? Did you keep close to the RI or
> did you implement a
> > > different solution?
> > >
> > > regards,
> > >
> > > Martin
> > >
> >
>
__________________________________
Yahoo! Music Unlimited
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/
Re: Super!
Posted by Adam Winer <aw...@gmail.com>.
This sounds roughly like the implementation of server-side
state saving in the JSF 1.2 RI, as well as what's done in ADF Faces,
though not exactly, 'cause there's differences in the details (neither,
for instance, supports putting sequence numbers into URLs, just
hidden fields).
What exactly do you mean by "the serialized view is now really
serialized (this was not the case before)"? Before, server-side
state saving (at least in 1.1 RI) was just stashing the UIViewRoot,
which dies for a bunch of reasons. I'm gonna guess that
you grab the SerializedView object with StateManager.saveState(),
and then save off its two components.
Getting per-request state to survive <redirect/>, like Mario's proposing,
is a separate issue, as you say.
-- Adam
On 10/18/05, Mathias Brökelmann <mb...@googlemail.com> wrote:
> Well, I have not taken a look into the ri for this issue. So I can not
> say if it is solved like the ri.
>
> This is what I have done:
>
> If server side state is uses the serialized view is now really
> serialized (this was not the case before) into the session by using
> the viewid and a sequence number. The sequence number will be rendered
> into the response (either as a hidden input field if used in forms or
> as a param in a url). This sequence could also be used for other
> things since it is increased by every request. The last sequence used
> is also stored into the session.
>
> To restore the response the viewid and the sequenceid from the request
> is used to determine the serialized view. The last 15 (currently fixed
> number) views will be saved into the session. I´ve utilized a
> ReferenceMap which uses SoftReference instances for the views after
> the 15th. So if the garbage collector doesn´t collect these values
> they are still available.
>
> I´ve done some testing so it seams to work. If anyone (maybe you
> Marting ;)) finds the time to make some more tests I would be very
> happy.
>
> Best Regards,
>
> Mathias
>
> 2005/10/18, Martin Marinschek <ma...@gmail.com>:
> > Mathias,
> >
> > wow - you have solved the server side state saving problem we have had for ages?
> >
> > That will make some users very, very happy!
> >
> > Thanks from the whole team, great news indeed.
> >
> > Do you want to give us (on the dev list) a short wrapup on how you
> > solved things? Did you keep close to the RI or did you implement a
> > different solution?
> >
> > regards,
> >
> > Martin
> >
>
Re: Super!
Posted by Mathias Brökelmann <mb...@googlemail.com>.
Well, I have not taken a look into the ri for this issue. So I can not
say if it is solved like the ri.
This is what I have done:
If server side state is uses the serialized view is now really
serialized (this was not the case before) into the session by using
the viewid and a sequence number. The sequence number will be rendered
into the response (either as a hidden input field if used in forms or
as a param in a url). This sequence could also be used for other
things since it is increased by every request. The last sequence used
is also stored into the session.
To restore the response the viewid and the sequenceid from the request
is used to determine the serialized view. The last 15 (currently fixed
number) views will be saved into the session. I´ve utilized a
ReferenceMap which uses SoftReference instances for the views after
the 15th. So if the garbage collector doesn´t collect these values
they are still available.
I´ve done some testing so it seams to work. If anyone (maybe you
Marting ;)) finds the time to make some more tests I would be very
happy.
Best Regards,
Mathias
2005/10/18, Martin Marinschek <ma...@gmail.com>:
> Mathias,
>
> wow - you have solved the server side state saving problem we have had for ages?
>
> That will make some users very, very happy!
>
> Thanks from the whole team, great news indeed.
>
> Do you want to give us (on the dev list) a short wrapup on how you
> solved things? Did you keep close to the RI or did you implement a
> different solution?
>
> regards,
>
> Martin
>