Re: Super!

[Mike Kienenberger]

The way I did it under struts was to set a "creation date" mapping to
each page.When pages were requested, before the page was looked
up, expiration dates were checked and expired pages were dumped.

My application was fairly low bandwidth, so I didn't spend much time
optimizing it, but I'd imagine you could record the "nearest creation
date" after each check, and then not do another full check until that
date was reached.Then it's just one comparison per request until
another full check gets triggered, at which point you'd check
everything again and generate a new "nearest creation date".

I think I also checked the expiration dates on session expiration
events.  Not sure if that's necessary.

On 10/20/05, Mathias Brökelmann <[EMAIL PROTECTED]> wrote:
> This sounds good to me. Any idea how we can implement it. The only
> solution I have is too have an additional thread running somewhere
> which checks for timeouts.
>
> 2005/10/20, Mike Kienenberger <[EMAIL PROTECTED]>:
> > I'd like to agree with Alexander on this one.   Sometimes, it's better
> > to be able to tell end users that their pages will expire after 5
> > minutes (or 5 hours) rather than saying they can only backtrack 15
> > views (most end-users have no idea what a "view" means).   Not all of
> > us need to tune our backtracking based solely on memory usage.
> >
> > -Mike
> >
> >
> > On 10/20/05, Mathias Brökelmann <[EMAIL PROTECTED]> wrote:
> > > IMO having a max number of views stored in the session is quite
> > > adequate for this. If the user navigates to other pages the oldest
> > > view is dropped if the max number is reached. Correct me if I´m wrong
> > > but this is different to the RI. AFAIK RI stores the last n views
> > > based on a view. So you can end up with:
> > >
> > > number of pages (view) * max number of saved views = max number of
> > > saved views in session
> > >
> > > I don´t like this solution since it produces unpredictable results in
> > > memory consumption. myfaces solution now stores only the last n number
> > > of rendered views in the session.
> > >
> > > If there is a memory problem the user might choose to use client side
> > > state instead or reduce the number of views in the session.
> > >
> > > 2005/10/20, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]>:
> > > > -Original Message-
> > > > 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)
> > > > -/Original Message-
> > > > Great... one less test/investigation I have to do before being able to
> > > > request that JSF gets mandatory for our company's webapps ;-)
> > > >
> > > > I am just now wondering whether a timeout value for such session-view
> > > > objects might make sense as a further tuning mechanism.
> > > > The idea is to sort of clean the session from view that are called only
> > > > once (eg. login-usecase) or very seldom...
> > > >
> > > > especially for big apps with lots of users this could be crucial.
> > > >
> > > > Or should we device something that would allow this mechanism to be
> > > > configured
> > > > per page. EG. the login pages do not need to remain in the session...
> > > >
> > > >
> > > > regards
> > > > Alexander
> > > >
> > >
> > >
> > > --
> > > Mathias
> > >
> >
>
>
> --
> Mathias
>

RE: Super!

[Jesse Alexander \(KBSA 21\)]

-Original Message-
This sounds good to me. Any idea how we can implement it. The only
solution I have is too have an additional thread running somewhere
which checks for timeouts.
-/Original Message-
Put a bean into application context, which gets the info about actual
sessions
from a session listener. Now let that bean be called every now and
then...
EG. from every (100th) request?

Or at the end of the request-processing call a bean that ages out the 
old pages. Plus a session-listener that listens only for the
session-timeouts.

regards
Alexander

PS: discussion like that can be done well on the IRC-channel (just
remember to post a summary to the list...)

Re: Super!

[Mathias Brökelmann]

This sounds good to me. Any idea how we can implement it. The only
solution I have is too have an additional thread running somewhere
which checks for timeouts.

2005/10/20, Mike Kienenberger <[EMAIL PROTECTED]>:
> I'd like to agree with Alexander on this one.   Sometimes, it's better
> to be able to tell end users that their pages will expire after 5
> minutes (or 5 hours) rather than saying they can only backtrack 15
> views (most end-users have no idea what a "view" means).   Not all of
> us need to tune our backtracking based solely on memory usage.
>
> -Mike
>
>
> On 10/20/05, Mathias Brökelmann <[EMAIL PROTECTED]> wrote:
> > IMO having a max number of views stored in the session is quite
> > adequate for this. If the user navigates to other pages the oldest
> > view is dropped if the max number is reached. Correct me if I´m wrong
> > but this is different to the RI. AFAIK RI stores the last n views
> > based on a view. So you can end up with:
> >
> > number of pages (view) * max number of saved views = max number of
> > saved views in session
> >
> > I don´t like this solution since it produces unpredictable results in
> > memory consumption. myfaces solution now stores only the last n number
> > of rendered views in the session.
> >
> > If there is a memory problem the user might choose to use client side
> > state instead or reduce the number of views in the session.
> >
> > 2005/10/20, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]>:
> > > -Original Message-
> > > 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)
> > > -/Original Message-
> > > Great... one less test/investigation I have to do before being able to
> > > request that JSF gets mandatory for our company's webapps ;-)
> > >
> > > I am just now wondering whether a timeout value for such session-view
> > > objects might make sense as a further tuning mechanism.
> > > The idea is to sort of clean the session from view that are called only
> > > once (eg. login-usecase) or very seldom...
> > >
> > > especially for big apps with lots of users this could be crucial.
> > >
> > > Or should we device something that would allow this mechanism to be
> > > configured
> > > per page. EG. the login pages do not need to remain in the session...
> > >
> > >
> > > regards
> > > Alexander
> > >
> >
> >
> > --
> > Mathias
> >
>


--
Mathias

Re: Super!

[Mike Kienenberger]

I'd like to agree with Alexander on this one.   Sometimes, it's better
to be able to tell end users that their pages will expire after 5
minutes (or 5 hours) rather than saying they can only backtrack 15
views (most end-users have no idea what a "view" means).   Not all of
us need to tune our backtracking based solely on memory usage.

-Mike


On 10/20/05, Mathias Brökelmann <[EMAIL PROTECTED]> wrote:
> IMO having a max number of views stored in the session is quite
> adequate for this. If the user navigates to other pages the oldest
> view is dropped if the max number is reached. Correct me if I´m wrong
> but this is different to the RI. AFAIK RI stores the last n views
> based on a view. So you can end up with:
>
> number of pages (view) * max number of saved views = max number of
> saved views in session
>
> I don´t like this solution since it produces unpredictable results in
> memory consumption. myfaces solution now stores only the last n number
> of rendered views in the session.
>
> If there is a memory problem the user might choose to use client side
> state instead or reduce the number of views in the session.
>
> 2005/10/20, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]>:
> > -Original Message-
> > 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)
> > -/Original Message-
> > Great... one less test/investigation I have to do before being able to
> > request that JSF gets mandatory for our company's webapps ;-)
> >
> > I am just now wondering whether a timeout value for such session-view
> > objects might make sense as a further tuning mechanism.
> > The idea is to sort of clean the session from view that are called only
> > once (eg. login-usecase) or very seldom...
> >
> > especially for big apps with lots of users this could be crucial.
> >
> > Or should we device something that would allow this mechanism to be
> > configured
> > per page. EG. the login pages do not need to remain in the session...
> >
> >
> > regards
> > Alexander
> >
>
>
> --
> Mathias
>

RE: Super!

[Jesse Alexander \(KBSA 21\)]

-Original Message-
IMO having a max number of views stored in the session is quite
adequate for this. If the user navigates to other pages the oldest
view is dropped if the max number is reached. Correct me if I´m wrong
but this is different to the RI. AFAIK RI stores the last n views
based on a view. So you can end up with:

number of pages (view) * max number of saved views = max number of
saved views in session

I don´t like this solution since it produces unpredictable results in
memory consumption. myfaces solution now stores only the last n number
of rendered views in the session.

If there is a memory problem the user might choose to use client side
state instead or reduce the number of views in the session.
-/Original Message-
And if the mechanism is not depending on the fact to always expect
a "cache-hit" for the yiew, it would be possible to use a session-listener
to do the additional cleanup anyway.

regards
Alexander

Re: Super!

[Mathias Brökelmann]

IMO having a max number of views stored in the session is quite
adequate for this. If the user navigates to other pages the oldest
view is dropped if the max number is reached. Correct me if I´m wrong
but this is different to the RI. AFAIK RI stores the last n views
based on a view. So you can end up with:

number of pages (view) * max number of saved views = max number of
saved views in session

I don´t like this solution since it produces unpredictable results in
memory consumption. myfaces solution now stores only the last n number
of rendered views in the session.

If there is a memory problem the user might choose to use client side
state instead or reduce the number of views in the session.

2005/10/20, Jesse Alexander (KBSA 21) <[EMAIL PROTECTED]>:
> -Original Message-
> 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)
> -/Original Message-
> Great... one less test/investigation I have to do before being able to
> request that JSF gets mandatory for our company's webapps ;-)
>
> I am just now wondering whether a timeout value for such session-view
> objects might make sense as a further tuning mechanism.
> The idea is to sort of clean the session from view that are called only
> once (eg. login-usecase) or very seldom...
>
> especially for big apps with lots of users this could be crucial.
>
> Or should we device something that would allow this mechanism to be
> configured
> per page. EG. the login pages do not need to remain in the session...
>
>
> regards
> Alexander
>


--
Mathias

RE: Super!

[Jesse Alexander \(KBSA 21\)]

-Original Message-
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)
-/Original Message-
Great... one less test/investigation I have to do before being able to
request that JSF gets mandatory for our company's webapps ;-)

I am just now wondering whether a timeout value for such session-view
objects might make sense as a further tuning mechanism.
The idea is to sort of clean the session from view that are called only
once (eg. login-usecase) or very seldom...

especially for big apps with lots of users this could be crucial.

Or should we device something that would allow this mechanism to be
configured
per page. EG. the login pages do not need to remain in the session...


regards
Alexander

Re: Super!

[Mathias Brökelmann]

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 <[EMAIL PROTECTED]>:
> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>:
> > > 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!

[Werner Punz]

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!

[Mathias Brökelmann]

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 <[EMAIL PROTECTED]>:
> 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* <[EMAIL PROTECTED]
> > > 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 <[EMAIL PROTECTED] >:
> >  > 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!

[Simon Kitching]

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* <[EMAIL PROTECTED] 
> 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 <[EMAIL PROTECTED] >:
 > 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!

[Adam Winer]

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?
-- AdamOn 10/19/05, Mathias Brökelmann <[EMAIL PROTECTED]> wrote:
You are right the two objects in SerailizedView are serialized and putinto the session.
The instances of the server side state where not serialized before.This doesn´t affect the component instances since they are onlyreferenced by class name in the state but it could have an effect onthe 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 nowbetter supported because the user will see a NotSerializeableExceptionimmediatly if a value of the state is not serializable.
2005/10/18, Adam Winer <[EMAIL PROTECTED]>:> 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!

[Martin Marinschek]

That is my only feature enhancement wish as well ;)

regards,

Martin

On 10/19/05, sharath reddy <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 ,
> > like Mario's proposing,
> > is a separate issue, as you say.
> >
> > -- Adam
> >
> >
> > On 10/18/05, Mathias Brökelmann
> > <[EMAIL PROTECTED]> 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
> > <[EMAIL PROTECTED]>:
> > > > 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!

[sharath reddy]

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 <[EMAIL PROTECTED]> 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 ,
> like Mario's proposing,
> is a separate issue, as you say.
> 
> -- Adam
> 
> 
> On 10/18/05, Mathias Brökelmann
> <[EMAIL PROTECTED]> 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
> <[EMAIL PROTECTED]>:
> > > 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!

[ir. ing. Jan Dockx]

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 <[EMAIL PROTECTED]>:
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 , like Mario's
proposing,
is a separate issue, as you say.

-- Adam


On 10/18/05, Mathias Brökelmann <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>:
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/


smime.p7s
Description: S/MIME cryptographic signature

Re: Super!

[Mathias Brökelmann]

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 <[EMAIL PROTECTED]>:
> 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!

[Mathias Brökelmann]

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 <[EMAIL PROTECTED]>:
> 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 , like Mario's
> > proposing,
> > is a separate issue, as you say.
> >
> > -- Adam
> >
> >
> > On 10/18/05, Mathias Brökelmann <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>:
> >>> 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!

[ir. ing. Jan Dockx]

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 , like Mario's proposing,
is a separate issue, as you say.

-- Adam


On 10/18/05, Mathias Brökelmann <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>:
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/


smime.p7s
Description: S/MIME cryptographic signature

Re: Super!

[Adam Winer]

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 , like Mario's proposing,
is a separate issue, as you say.

-- Adam


On 10/18/05, Mathias Brökelmann <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>:
> > 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!

[Mario Ivankovits]

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 "" 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!

[Mathias Brökelmann]

Redirection is not handled. Neither by client nor by server side state saving.

2005/10/18, Mario Ivankovits <[EMAIL PROTECTED]>:
> 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 
> 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!

[Werner Punz]

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!

[Mario Ivankovits]

Mario Ivankovits wrote:

http://issues.apache.org/jira/browse/MYFACES-516

Oh, and I tried to survive the messages too.

---
Mario

Re: Super!

[Mario Ivankovits]

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 

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!

[Martin Marinschek]

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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>:
> > 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!

[Mathias Brökelmann]

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 <[EMAIL PROTECTED]>:
> 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
>