You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Allen Gilbert <al...@doane.edu> on 2012/04/23 03:59:08 UTC
StalePageException handling issue
While trying to understand what causes StalePageExceptions (using Wicket
1.5.4), I discovered a strange situation that can occur
when DefaultExceptionMapper handles a StalePageException. I decided to ping
the mailing list before creating a JIRA issue in case I'm misunderstanding
intended behavior.
Consider this scenario:
1) A user logs in and loads a few different pages, eventually landing on
Page A. At this point, Page A's version is "5", e.g. /some/path/pageA?5
2) The user opens a new tab and loads Page B
3) The user logs out (or their session times out) while on Page B
4) The user logs back in and interacts with Page B, performing page-level
actions that increase the render count of the page, until Page B's version
is "5." At this point, a link listener url on Page B looks something like
/some/path/pageB?5-3.ILinkListener-someLink
5) The user switches back to their old Page A tab
6) The user clicks an action link (with a listener url
like /some/path/pageA?5-1.ILinkListener-someLink) on Page A
7) Wicket throws a StalePageException because the page with version "5" has
a render count of 3, not 1
8) At this point, the strange thing occurs: instead of rendering a new
version of Page A, Wicket renders Page B. Thus, even though the user
attempted to do something on Page A, they are now looking at Page B.
Digging into the code, it seems this is due to the implementation of
PageProvider.getStoredPage(int pageId). Notably, the javadoc for the
method states, "If pageClass is specified then compares it against the
stored instance class and returns the found instance only if they match."
In the example, pageClass would be PageA.class,
but storedPageInstance.getClass() would return PageB.class (the page with
id=5 in the newest session). However, even though pageClass
and storedPageInstance.getClass() aren't equal, the method still
returns storedPageInstance.
In this case, shouldn't getStoredPage() should return null, prompting a
fresh instantiation of PageA.class? That way, when the user clicks the
stale link on Page A, they'll get a fresh rendering of Page A.
Thanks for your help!
-Allen
Re: StalePageException handling issue
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
Open a stateful page in a tab/window, then copy the url from the address
bar and open it in a new tab/window.
Then go back to the first tab/window and try to click on any stateful link.
This will lead to StalePageException.
It is thrown because Wicket detects that the same page instance has been
rendered between the render of the current page and the click on the link.
Wicket does this because it is not sure whether there are any changes in
the page tree hierarchy between the initial rendering and the click event.
It is even possible that this link is no more existing in the last version
of the page, so this click could lead to ComponentNotFoundException if
StalePageException is not thrown earlier.
StalePageException just leads to render of the current page. So the user
will see the last version of the page and (s)he will need to click the link
again.
On Tue, Dec 18, 2012 at 4:47 PM, amit.jha <am...@hcl.com> wrote:
> Hi,
>
> Thanks for your posting.
>
> I am working on some application and was getting stalePageException.The sad
> part of this is that i do not know how it is reproduciable.I searched in
> the
> forums and tried all suggested ways of reproducing it,but fail to reproduce
> it. What i observed in my application is that whenever i was getting
> SessionExpiry Page in my application,i encountered the stalePageException
> and based on that i am suspecting that it was coming due to that.But now ,
> sessionExpiray page is not coming as well as not stalePageException. I am
> using wicket 1.5.7.
>
> Do you have idea, what all other ways by which it can be reproducible? i
> tried all combination of reproducing it based on as much knowledge i have
> in
> wicket but failed to reproduce it.I have to give some reason to my teams
> that why it was coming earlier and why it is not coming now and kind of
> concrete reasoning. Any help would be highly appreciated.
> Thanks in advance
>
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/StalePageException-handling-issue-tp4579247p4654887.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com <http://jweekend.com/>
Re: StalePageException handling issue
Posted by "amit.jha" <am...@hcl.com>.
Hi,
Thanks for your posting.
I am working on some application and was getting stalePageException.The sad
part of this is that i do not know how it is reproduciable.I searched in the
forums and tried all suggested ways of reproducing it,but fail to reproduce
it. What i observed in my application is that whenever i was getting
SessionExpiry Page in my application,i encountered the stalePageException
and based on that i am suspecting that it was coming due to that.But now ,
sessionExpiray page is not coming as well as not stalePageException. I am
using wicket 1.5.7.
Do you have idea, what all other ways by which it can be reproducible? i
tried all combination of reproducing it based on as much knowledge i have in
wicket but failed to reproduce it.I have to give some reason to my teams
that why it was coming earlier and why it is not coming now and kind of
concrete reasoning. Any help would be highly appreciated.
Thanks in advance
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/StalePageException-handling-issue-tp4579247p4654887.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: StalePageException handling issue
Posted by Allen Gilbert <al...@doane.edu>.
Excellent. Thanks!
On Mon, Apr 23, 2012 at 2:22 AM, Martin Grigorov <mg...@apache.org>wrote:
> Hi Allen,
>
> This is improved in 1.5-SNAPSHOT and will be part of 1.5.6.
> See https://issues.apache.org/jira/browse/WICKET-4488 and
> https://issues.apache.org/jira/browse/WICKET-4441
>
> On Mon, Apr 23, 2012 at 4:59 AM, Allen Gilbert <al...@doane.edu>
> wrote:
> > While trying to understand what causes StalePageExceptions (using Wicket
> > 1.5.4), I discovered a strange situation that can occur
> > when DefaultExceptionMapper handles a StalePageException. I decided to
> ping
> > the mailing list before creating a JIRA issue in case I'm
> misunderstanding
> > intended behavior.
> >
> > Consider this scenario:
> >
> > 1) A user logs in and loads a few different pages, eventually landing on
> > Page A. At this point, Page A's version is "5", e.g. /some/path/pageA?5
> > 2) The user opens a new tab and loads Page B
> > 3) The user logs out (or their session times out) while on Page B
> > 4) The user logs back in and interacts with Page B, performing page-level
> > actions that increase the render count of the page, until Page B's
> version
> > is "5." At this point, a link listener url on Page B looks something
> like
> > /some/path/pageB?5-3.ILinkListener-someLink
> > 5) The user switches back to their old Page A tab
> > 6) The user clicks an action link (with a listener url
> > like /some/path/pageA?5-1.ILinkListener-someLink) on Page A
> > 7) Wicket throws a StalePageException because the page with version "5"
> has
> > a render count of 3, not 1
> > 8) At this point, the strange thing occurs: instead of rendering a new
> > version of Page A, Wicket renders Page B. Thus, even though the user
> > attempted to do something on Page A, they are now looking at Page B.
> >
> > Digging into the code, it seems this is due to the implementation of
> > PageProvider.getStoredPage(int pageId). Notably, the javadoc for the
> > method states, "If pageClass is specified then compares it against the
> > stored instance class and returns the found instance only if they match."
> > In the example, pageClass would be PageA.class,
> > but storedPageInstance.getClass() would return PageB.class (the page with
> > id=5 in the newest session). However, even though pageClass
> > and storedPageInstance.getClass() aren't equal, the method still
> > returns storedPageInstance.
> >
> > In this case, shouldn't getStoredPage() should return null, prompting a
> > fresh instantiation of PageA.class? That way, when the user clicks the
> > stale link on Page A, they'll get a fresh rendering of Page A.
> >
> > Thanks for your help!
> >
> > -Allen
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: StalePageException handling issue
Posted by Martin Grigorov <mg...@apache.org>.
Hi Allen,
This is improved in 1.5-SNAPSHOT and will be part of 1.5.6.
See https://issues.apache.org/jira/browse/WICKET-4488 and
https://issues.apache.org/jira/browse/WICKET-4441
On Mon, Apr 23, 2012 at 4:59 AM, Allen Gilbert <al...@doane.edu> wrote:
> While trying to understand what causes StalePageExceptions (using Wicket
> 1.5.4), I discovered a strange situation that can occur
> when DefaultExceptionMapper handles a StalePageException. I decided to ping
> the mailing list before creating a JIRA issue in case I'm misunderstanding
> intended behavior.
>
> Consider this scenario:
>
> 1) A user logs in and loads a few different pages, eventually landing on
> Page A. At this point, Page A's version is "5", e.g. /some/path/pageA?5
> 2) The user opens a new tab and loads Page B
> 3) The user logs out (or their session times out) while on Page B
> 4) The user logs back in and interacts with Page B, performing page-level
> actions that increase the render count of the page, until Page B's version
> is "5." At this point, a link listener url on Page B looks something like
> /some/path/pageB?5-3.ILinkListener-someLink
> 5) The user switches back to their old Page A tab
> 6) The user clicks an action link (with a listener url
> like /some/path/pageA?5-1.ILinkListener-someLink) on Page A
> 7) Wicket throws a StalePageException because the page with version "5" has
> a render count of 3, not 1
> 8) At this point, the strange thing occurs: instead of rendering a new
> version of Page A, Wicket renders Page B. Thus, even though the user
> attempted to do something on Page A, they are now looking at Page B.
>
> Digging into the code, it seems this is due to the implementation of
> PageProvider.getStoredPage(int pageId). Notably, the javadoc for the
> method states, "If pageClass is specified then compares it against the
> stored instance class and returns the found instance only if they match."
> In the example, pageClass would be PageA.class,
> but storedPageInstance.getClass() would return PageB.class (the page with
> id=5 in the newest session). However, even though pageClass
> and storedPageInstance.getClass() aren't equal, the method still
> returns storedPageInstance.
>
> In this case, shouldn't getStoredPage() should return null, prompting a
> fresh instantiation of PageA.class? That way, when the user clicks the
> stale link on Page A, they'll get a fresh rendering of Page A.
>
> Thanks for your help!
>
> -Allen
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org