You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-dev@incubator.apache.org by Alexander Smirnov <as...@exadel.com> on 2006/09/25 19:45:56 UTC
Possible bug in StateManager
I work for compability on Apache Trinidad and ajax4jsf project, and,
after solve all My problems have one incompability with client-side
saving state.
As I see, in Trinidad StateManagerImpl, ViewRoot not pass save/restore
state methods, but manager simple created new instance of UIViewRoot
class, and copy any properties from cached instance to new. This code
will be source of problem in any realisations expect SUN RI 1.1 - since
in MyFaces and JSF 1.2 implementations viewRoot have more persistanse
parameters ( at least, must be restored unique id's counter, and lot of
listeners in JSF 1.2 ).
And, In may case, redefine class for ViewRoot component in
faces-config.xml break after first restore tree state.
--
===============================================
Alexander J. Smirnov
http://smirnov.org.ru/en/
Exadel Inc.
e-mail: asmirnov@exadel.com
ICQ: 69173529
===============================================
Re: Possible bug in StateManager
Posted by Arjuna Wijeyekoon <ar...@gmail.com>.
fixed. note that I still could not cache the UIViewRoot because of the
problems mentioned in the JIRA.
However, I am using the Application to create the new UIViewRoot,and I am
using save/restoreState, so
all the issues should be cleared up, and we still have the restoreState
optimization in place.
--arjuna
On 9/29/06, Arjuna Wijeyekoon <ar...@gmail.com> wrote:
>
> http://issues.apache.org/jira/browse/ADFFACES-209
>
>
>
> On 9/26/06, Arjuna Wijeyekoon < arjuna@gmail.com> wrote:
> >
> > ok, I will file a JIRA issue for this and fix it this weekend.
> >
> > On 9/25/06, Alexander Smirnov < asmirnov@exadel.com > wrote:
> > >
> > > Two solutions for same problem breacks togewer :-)
> > > I have overriede UIViewRoot due to same problem, for keep evens queue
> > > (
> > > also as uniqueId counter etc ) in own request-scope context.
> > > Messages not affected by this issue, since it stored in FacesContext
> > > and
> > > have instances per request.
> > >
> > > Also, I found You configuration flag, but it really not used in code.
> > >
> > > Adam Winer wrote:
> > >
> > > > On 9/25/06, Alexander Smirnov <as...@exadel.com> wrote:
> > > >
> > > >>
> > > >> I work for compability on Apache Trinidad and ajax4jsf project,
> > > and,
> > > >> after solve all My problems have one incompability with client-side
> > > >> saving state.
> > > >> As I see, in Trinidad StateManagerImpl, ViewRoot not pass
> > > save/restore
> > > >> state methods, but manager simple created new instance of
> > > UIViewRoot
> > > >> class, and copy any properties from cached instance to new. This
> > > code
> > > >> will be source of problem in any realisations expect SUN RI 1.1 -
> > > since
> > > >> in MyFaces and JSF 1.2 implementations viewRoot have more
> > > persistanse
> > > >> parameters ( at least, must be restored unique id's counter, and
> > > lot of
> > > >> listeners in JSF 1.2 ).
> > > >
> > > >
> > > >
> > > > We wanted to simply cache the UIViewRoot itself, but there were
> > > > problems in JSF 1.1 with events (and maybe also messages?)
> > > > not getting cleared. So, you have a pending ActionEvent in
> > > > the queue, but validation fails - then you get two ActionEvents
> > > > the next time around!
> > > >
> > > > This led to us re-creating the UIViewRoot. The preferred solution
> > > > is making sure that we can simply cache the original UIViewRoot
> > > > itself. But simply saving and restoring sufficient state should
> > > > be enough, so I figure we could just call UIViewRoot.saveState()
> > > > and UIViewRoot.restoreState().
> > > >
> > > > I'm willing to add a configuration flag to disable this optimization
> > > -
> > > > which
> > > > is a very significant one - but would not want to turn it off by
> > > > default.
> > > >
> > > > And, In may case, redefine class for ViewRoot component in
> > > >
> > > >> faces-config.xml break after first restore tree state
> > > >
> > > >
> > > >
> > > > Yes, though that should be cleanly fixed simply by going through
> > > > Application.createComponent() to create the UIViewRoot.
> > > >
> > > > -- Adam
> > > >
> > >
> > >
> > > --
> > > ===============================================
> > > Alexander J. Smirnov
> > > http://smirnov.org.ru/en/
> > > Exadel Inc.
> > > e-mail: asmirnov@exadel.com
> > > ICQ: 69173529
> > > ===============================================
> > >
> > >
> >
>
Re: Possible bug in StateManager
Posted by Arjuna Wijeyekoon <ar...@gmail.com>.
http://issues.apache.org/jira/browse/ADFFACES-209
On 9/26/06, Arjuna Wijeyekoon <ar...@gmail.com> wrote:
>
> ok, I will file a JIRA issue for this and fix it this weekend.
>
> On 9/25/06, Alexander Smirnov <asmirnov@exadel.com > wrote:
> >
> > Two solutions for same problem breacks togewer :-)
> > I have overriede UIViewRoot due to same problem, for keep evens queue (
> > also as uniqueId counter etc ) in own request-scope context.
> > Messages not affected by this issue, since it stored in FacesContext and
> > have instances per request.
> >
> > Also, I found You configuration flag, but it really not used in code.
> >
> > Adam Winer wrote:
> >
> > > On 9/25/06, Alexander Smirnov <as...@exadel.com> wrote:
> > >
> > >>
> > >> I work for compability on Apache Trinidad and ajax4jsf project, and,
> > >> after solve all My problems have one incompability with client-side
> > >> saving state.
> > >> As I see, in Trinidad StateManagerImpl, ViewRoot not pass
> > save/restore
> > >> state methods, but manager simple created new instance of UIViewRoot
> > >> class, and copy any properties from cached instance to new. This code
> > >> will be source of problem in any realisations expect SUN RI 1.1 -
> > since
> > >> in MyFaces and JSF 1.2 implementations viewRoot have more persistanse
> >
> > >> parameters ( at least, must be restored unique id's counter, and lot
> > of
> > >> listeners in JSF 1.2 ).
> > >
> > >
> > >
> > > We wanted to simply cache the UIViewRoot itself, but there were
> > > problems in JSF 1.1 with events (and maybe also messages?)
> > > not getting cleared. So, you have a pending ActionEvent in
> > > the queue, but validation fails - then you get two ActionEvents
> > > the next time around!
> > >
> > > This led to us re-creating the UIViewRoot. The preferred solution
> > > is making sure that we can simply cache the original UIViewRoot
> > > itself. But simply saving and restoring sufficient state should
> > > be enough, so I figure we could just call UIViewRoot.saveState()
> > > and UIViewRoot.restoreState().
> > >
> > > I'm willing to add a configuration flag to disable this optimization -
> > > which
> > > is a very significant one - but would not want to turn it off by
> > > default.
> > >
> > > And, In may case, redefine class for ViewRoot component in
> > >
> > >> faces-config.xml break after first restore tree state
> > >
> > >
> > >
> > > Yes, though that should be cleanly fixed simply by going through
> > > Application.createComponent() to create the UIViewRoot.
> > >
> > > -- Adam
> > >
> >
> >
> > --
> > ===============================================
> > Alexander J. Smirnov
> > http://smirnov.org.ru/en/
> > Exadel Inc.
> > e-mail: asmirnov@exadel.com
> > ICQ: 69173529
> > ===============================================
> >
> >
>
Re: Possible bug in StateManager
Posted by Arjuna Wijeyekoon <ar...@gmail.com>.
ok, I will file a JIRA issue for this and fix it this weekend.
On 9/25/06, Alexander Smirnov <as...@exadel.com> wrote:
>
> Two solutions for same problem breacks togewer :-)
> I have overriede UIViewRoot due to same problem, for keep evens queue (
> also as uniqueId counter etc ) in own request-scope context.
> Messages not affected by this issue, since it stored in FacesContext and
> have instances per request.
>
> Also, I found You configuration flag, but it really not used in code.
>
> Adam Winer wrote:
>
> > On 9/25/06, Alexander Smirnov <as...@exadel.com> wrote:
> >
> >>
> >> I work for compability on Apache Trinidad and ajax4jsf project, and,
> >> after solve all My problems have one incompability with client-side
> >> saving state.
> >> As I see, in Trinidad StateManagerImpl, ViewRoot not pass save/restore
> >> state methods, but manager simple created new instance of UIViewRoot
> >> class, and copy any properties from cached instance to new. This code
> >> will be source of problem in any realisations expect SUN RI 1.1 - since
> >> in MyFaces and JSF 1.2 implementations viewRoot have more persistanse
> >> parameters ( at least, must be restored unique id's counter, and lot of
> >> listeners in JSF 1.2 ).
> >
> >
> >
> > We wanted to simply cache the UIViewRoot itself, but there were
> > problems in JSF 1.1 with events (and maybe also messages?)
> > not getting cleared. So, you have a pending ActionEvent in
> > the queue, but validation fails - then you get two ActionEvents
> > the next time around!
> >
> > This led to us re-creating the UIViewRoot. The preferred solution
> > is making sure that we can simply cache the original UIViewRoot
> > itself. But simply saving and restoring sufficient state should
> > be enough, so I figure we could just call UIViewRoot.saveState()
> > and UIViewRoot.restoreState().
> >
> > I'm willing to add a configuration flag to disable this optimization -
> > which
> > is a very significant one - but would not want to turn it off by
> > default.
> >
> > And, In may case, redefine class for ViewRoot component in
> >
> >> faces-config.xml break after first restore tree state
> >
> >
> >
> > Yes, though that should be cleanly fixed simply by going through
> > Application.createComponent() to create the UIViewRoot.
> >
> > -- Adam
> >
>
>
> --
> ===============================================
> Alexander J. Smirnov
> http://smirnov.org.ru/en/
> Exadel Inc.
> e-mail: asmirnov@exadel.com
> ICQ: 69173529
> ===============================================
>
>
Re: Possible bug in StateManager
Posted by Alexander Smirnov <as...@exadel.com>.
Two solutions for same problem breacks togewer :-)
I have overriede UIViewRoot due to same problem, for keep evens queue (
also as uniqueId counter etc ) in own request-scope context.
Messages not affected by this issue, since it stored in FacesContext and
have instances per request.
Also, I found You configuration flag, but it really not used in code.
Adam Winer wrote:
> On 9/25/06, Alexander Smirnov <as...@exadel.com> wrote:
>
>>
>> I work for compability on Apache Trinidad and ajax4jsf project, and,
>> after solve all My problems have one incompability with client-side
>> saving state.
>> As I see, in Trinidad StateManagerImpl, ViewRoot not pass save/restore
>> state methods, but manager simple created new instance of UIViewRoot
>> class, and copy any properties from cached instance to new. This code
>> will be source of problem in any realisations expect SUN RI 1.1 - since
>> in MyFaces and JSF 1.2 implementations viewRoot have more persistanse
>> parameters ( at least, must be restored unique id's counter, and lot of
>> listeners in JSF 1.2 ).
>
>
>
> We wanted to simply cache the UIViewRoot itself, but there were
> problems in JSF 1.1 with events (and maybe also messages?)
> not getting cleared. So, you have a pending ActionEvent in
> the queue, but validation fails - then you get two ActionEvents
> the next time around!
>
> This led to us re-creating the UIViewRoot. The preferred solution
> is making sure that we can simply cache the original UIViewRoot
> itself. But simply saving and restoring sufficient state should
> be enough, so I figure we could just call UIViewRoot.saveState()
> and UIViewRoot.restoreState().
>
> I'm willing to add a configuration flag to disable this optimization -
> which
> is a very significant one - but would not want to turn it off by
> default.
>
> And, In may case, redefine class for ViewRoot component in
>
>> faces-config.xml break after first restore tree state
>
>
>
> Yes, though that should be cleanly fixed simply by going through
> Application.createComponent() to create the UIViewRoot.
>
> -- Adam
>
--
===============================================
Alexander J. Smirnov
http://smirnov.org.ru/en/
Exadel Inc.
e-mail: asmirnov@exadel.com
ICQ: 69173529
===============================================
Re: Possible bug in StateManager
Posted by Arjuna Wijeyekoon <ar...@gmail.com>.
ah, I see. makes sense,
--arjuna
On 9/25/06, Adam Winer <aw...@gmail.com> wrote:
>
> On 9/25/06, Arjuna Wijeyekoon <ar...@gmail.com> wrote:
> >
> > >
> > > The preferred solution
> > > is making sure that we can simply cache the original UIViewRoot
> > > itself. But simply saving and restoring sufficient state should
> > > be enough, so I figure we could just call UIViewRoot.saveState()
> > > and UIViewRoot.restoreState().
> >
> >
> >
> > do you mean something like this: remove all the children from the
> > UIViewRoot, then call restoreState() on it,
>
>
>
> *restoreState()*, not *processRestoreState()*.
>
> saveState() and restoreState() are single-component, not full tree.
> So no need to add/remove anything.
>
> -- Adam
>
>
> (so that we don't incur the cost of a full restoreState walk on the
> > component tree)
> > and then add the children on to the UIViewRoot again.
> >
> >
> > > And, In may case, redefine class for ViewRoot component in
> > > > faces-config.xml break after first restore tree state
> > >
> > >
> > >
> > > Yes, though that should be cleanly fixed simply by going through
> > > Application.createComponent() to create the UIViewRoot.
> >
> >
> >
> > good idea. that is a trivial fix.
> > --arjuna
> >
> >
> > On 9/25/06, Adam Winer <aw...@gmail.com> wrote:
> > >
> > > On 9/25/06, Alexander Smirnov <as...@exadel.com> wrote:
> > > >
> > > > I work for compability on Apache Trinidad and ajax4jsf project, and,
> > > > after solve all My problems have one incompability with client-side
> > > > saving state.
> > > > As I see, in Trinidad StateManagerImpl, ViewRoot not pass
> save/restore
> > > > state methods, but manager simple created new instance of UIViewRoot
> > > > class, and copy any properties from cached instance to new. This
> code
> > > > will be source of problem in any realisations expect SUN RI 1.1 -
> > since
> > > > in MyFaces and JSF 1.2 implementations viewRoot have more
> persistanse
> > > > parameters ( at least, must be restored unique id's counter, and lot
> > of
> > > > listeners in JSF 1.2 ).
> > >
> > >
> > > We wanted to simply cache the UIViewRoot itself, but there were
> > > problems in JSF 1.1 with events (and maybe also messages?)
> > > not getting cleared. So, you have a pending ActionEvent in
> > > the queue, but validation fails - then you get two ActionEvents
> > > the next time around!
> > >
> > > This led to us re-creating the UIViewRoot. The preferred solution
> > > is making sure that we can simply cache the original UIViewRoot
> > > itself. But simply saving and restoring sufficient state should
> > > be enough, so I figure we could just call UIViewRoot.saveState()
> > > and UIViewRoot.restoreState().
> > >
> > > I'm willing to add a configuration flag to disable this optimization -
> > > which
> > > is a very significant one - but would not want to turn it off by
> > default.
> > >
> > > And, In may case, redefine class for ViewRoot component in
> > > > faces-config.xml break after first restore tree state
> > >
> > >
> > > Yes, though that should be cleanly fixed simply by going through
> > > Application.createComponent() to create the UIViewRoot.
> > >
> > > -- Adam
> > >
> > >
> >
> >
>
>
Re: Possible bug in StateManager
Posted by Adam Winer <aw...@gmail.com>.
On 9/25/06, Arjuna Wijeyekoon <ar...@gmail.com> wrote:
>
> >
> > The preferred solution
> > is making sure that we can simply cache the original UIViewRoot
> > itself. But simply saving and restoring sufficient state should
> > be enough, so I figure we could just call UIViewRoot.saveState()
> > and UIViewRoot.restoreState().
>
>
>
> do you mean something like this: remove all the children from the
> UIViewRoot, then call restoreState() on it,
*restoreState()*, not *processRestoreState()*.
saveState() and restoreState() are single-component, not full tree.
So no need to add/remove anything.
-- Adam
(so that we don't incur the cost of a full restoreState walk on the
> component tree)
> and then add the children on to the UIViewRoot again.
>
>
> > And, In may case, redefine class for ViewRoot component in
> > > faces-config.xml break after first restore tree state
> >
> >
> >
> > Yes, though that should be cleanly fixed simply by going through
> > Application.createComponent() to create the UIViewRoot.
>
>
>
> good idea. that is a trivial fix.
> --arjuna
>
>
> On 9/25/06, Adam Winer <aw...@gmail.com> wrote:
> >
> > On 9/25/06, Alexander Smirnov <as...@exadel.com> wrote:
> > >
> > > I work for compability on Apache Trinidad and ajax4jsf project, and,
> > > after solve all My problems have one incompability with client-side
> > > saving state.
> > > As I see, in Trinidad StateManagerImpl, ViewRoot not pass save/restore
> > > state methods, but manager simple created new instance of UIViewRoot
> > > class, and copy any properties from cached instance to new. This code
> > > will be source of problem in any realisations expect SUN RI 1.1 -
> since
> > > in MyFaces and JSF 1.2 implementations viewRoot have more persistanse
> > > parameters ( at least, must be restored unique id's counter, and lot
> of
> > > listeners in JSF 1.2 ).
> >
> >
> > We wanted to simply cache the UIViewRoot itself, but there were
> > problems in JSF 1.1 with events (and maybe also messages?)
> > not getting cleared. So, you have a pending ActionEvent in
> > the queue, but validation fails - then you get two ActionEvents
> > the next time around!
> >
> > This led to us re-creating the UIViewRoot. The preferred solution
> > is making sure that we can simply cache the original UIViewRoot
> > itself. But simply saving and restoring sufficient state should
> > be enough, so I figure we could just call UIViewRoot.saveState()
> > and UIViewRoot.restoreState().
> >
> > I'm willing to add a configuration flag to disable this optimization -
> > which
> > is a very significant one - but would not want to turn it off by
> default.
> >
> > And, In may case, redefine class for ViewRoot component in
> > > faces-config.xml break after first restore tree state
> >
> >
> > Yes, though that should be cleanly fixed simply by going through
> > Application.createComponent() to create the UIViewRoot.
> >
> > -- Adam
> >
> >
>
>
Re: Possible bug in StateManager
Posted by Arjuna Wijeyekoon <ar...@gmail.com>.
>
> The preferred solution
> is making sure that we can simply cache the original UIViewRoot
> itself. But simply saving and restoring sufficient state should
> be enough, so I figure we could just call UIViewRoot.saveState()
> and UIViewRoot.restoreState().
do you mean something like this: remove all the children from the
UIViewRoot, then call restoreState() on it,
(so that we don't incur the cost of a full restoreState walk on the
component tree)
and then add the children on to the UIViewRoot again.
> And, In may case, redefine class for ViewRoot component in
> > faces-config.xml break after first restore tree state
>
>
>
> Yes, though that should be cleanly fixed simply by going through
> Application.createComponent() to create the UIViewRoot.
good idea. that is a trivial fix.
--arjuna
On 9/25/06, Adam Winer <aw...@gmail.com> wrote:
>
> On 9/25/06, Alexander Smirnov <as...@exadel.com> wrote:
> >
> > I work for compability on Apache Trinidad and ajax4jsf project, and,
> > after solve all My problems have one incompability with client-side
> > saving state.
> > As I see, in Trinidad StateManagerImpl, ViewRoot not pass save/restore
> > state methods, but manager simple created new instance of UIViewRoot
> > class, and copy any properties from cached instance to new. This code
> > will be source of problem in any realisations expect SUN RI 1.1 - since
> > in MyFaces and JSF 1.2 implementations viewRoot have more persistanse
> > parameters ( at least, must be restored unique id's counter, and lot of
> > listeners in JSF 1.2 ).
>
>
> We wanted to simply cache the UIViewRoot itself, but there were
> problems in JSF 1.1 with events (and maybe also messages?)
> not getting cleared. So, you have a pending ActionEvent in
> the queue, but validation fails - then you get two ActionEvents
> the next time around!
>
> This led to us re-creating the UIViewRoot. The preferred solution
> is making sure that we can simply cache the original UIViewRoot
> itself. But simply saving and restoring sufficient state should
> be enough, so I figure we could just call UIViewRoot.saveState()
> and UIViewRoot.restoreState().
>
> I'm willing to add a configuration flag to disable this optimization -
> which
> is a very significant one - but would not want to turn it off by default.
>
> And, In may case, redefine class for ViewRoot component in
> > faces-config.xml break after first restore tree state
>
>
> Yes, though that should be cleanly fixed simply by going through
> Application.createComponent() to create the UIViewRoot.
>
> -- Adam
>
>
Re: Possible bug in StateManager
Posted by Adam Winer <aw...@gmail.com>.
On 9/25/06, Alexander Smirnov <as...@exadel.com> wrote:
>
> I work for compability on Apache Trinidad and ajax4jsf project, and,
> after solve all My problems have one incompability with client-side
> saving state.
> As I see, in Trinidad StateManagerImpl, ViewRoot not pass save/restore
> state methods, but manager simple created new instance of UIViewRoot
> class, and copy any properties from cached instance to new. This code
> will be source of problem in any realisations expect SUN RI 1.1 - since
> in MyFaces and JSF 1.2 implementations viewRoot have more persistanse
> parameters ( at least, must be restored unique id's counter, and lot of
> listeners in JSF 1.2 ).
We wanted to simply cache the UIViewRoot itself, but there were
problems in JSF 1.1 with events (and maybe also messages?)
not getting cleared. So, you have a pending ActionEvent in
the queue, but validation fails - then you get two ActionEvents
the next time around!
This led to us re-creating the UIViewRoot. The preferred solution
is making sure that we can simply cache the original UIViewRoot
itself. But simply saving and restoring sufficient state should
be enough, so I figure we could just call UIViewRoot.saveState()
and UIViewRoot.restoreState().
I'm willing to add a configuration flag to disable this optimization - which
is a very significant one - but would not want to turn it off by default.
And, In may case, redefine class for ViewRoot component in
> faces-config.xml break after first restore tree state
Yes, though that should be cleanly fixed simply by going through
Application.createComponent() to create the UIViewRoot.
-- Adam