Re: Page Map versions and Ajax Requests
1.5.3. I've narrowed the problem to a ListView being present on the page. Whenever there's a ListView with setReuseItems set to false (the default) the Page ID gets incremented whenever the back button is used to return to the page. I confirmed this with a call to getPage().getPageId() in an onComponentTag method. After returning via the back button the URL is still at the original Page ID while there's a newer version in the page map. Without a ListView present on the page using the back button does not increment the Page ID and everything works as expected. I have a quickstart app that illustrates the problem. Here is the page with the applicable code: http://pastebin.com/jn9czHK8 Mark On Friday, December 9, 2011 at 9:56 AM, Nazaret Kazarian wrote: Which version of Wicket are you using? 2011/12/7 Lichtenberg, Mark mlichtenb...@machenergy.com (mailto:mlichtenb...@machenergy.com): I have a page containing a number of AjaxLinks that when clicked fetch data and update some panels. When a user leaves one of these pages and returns via the back button the state of the page isn't always how they left it. However, this behavior happens only when the page is returned to the second time. Using the the request logger I've been able to partially explain this with the page IDs: 1. First visit to page X has a page ID of 3 2. AjaxLink requests for this page also have a page ID of 3. 3. User leaves page then returns to page X via the back button; this request also has ID of 3 4. User clicks AjaxLinks again, but here a new X page is created with an ID of 5 5. User leaves page and again returns with the back button. Here the page state is as they left it in #2, and the URL confirms the page ID of 3 I understand using the back button will always take the user to ID 3 since it is present in the URL. My workaround so far is to add the Page component to the target of my AjaxLink onClick()s. This increments the page ID whenever an AjaxLink is clicked and is reflected in the URL, so the back button always returns to the last state. So I have two questions - Why is a new page X created in step 4 above, and why does adding the Page component to the ajax request target make a new page map entry? Thanks, Mark - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org (mailto:users-unsubscr...@wicket.apache.org) For additional commands, e-mail: users-h...@wicket.apache.org (mailto:users-h...@wicket.apache.org)
Re: Page Map versions and Ajax Requests
That's exactly what I'm experiencing. In 1.5 it appears there's a few extra requests during a reload that I assume are retrieving the latest page version. I'll create a bug report. Thanks for your help. Mark On Friday, December 9, 2011 at 1:26 PM, Dan Retzlaff wrote: I confirmed this behavior in our application. Simply reloading a page with a ListView a few times advances the page ID but not the URL. AJAX links know to target the new page ID, but any updates they make get lost if the page gets reloaded from the URL. Sounds like a bug to me. Wicket 1.4 didn't behave this way. On Fri, Dec 9, 2011 at 10:26 AM, Dan Retzlaff dretzl...@gmail.com (mailto:dretzl...@gmail.com) wrote: Without reusing the ListView items, the item.add(...) will get called with each render. I expect that'll cause MarkupContainer#addedComponent() to WebPage#componentAdded() to WebPage#dirty() which sets a new page ID. Sorry I don't have time to test the theory at the moment. On Fri, Dec 9, 2011 at 8:27 AM, Mark Lichtenberg mlichtenb...@machenergy.com (mailto:mlichtenb...@machenergy.com) wrote: 1.5.3. I've narrowed the problem to a ListView being present on the page. Whenever there's a ListView with setReuseItems set to false (the default) the Page ID gets incremented whenever the back button is used to return to the page. I confirmed this with a call to getPage().getPageId() in an onComponentTag method. After returning via the back button the URL is still at the original Page ID while there's a newer version in the page map. Without a ListView present on the page using the back button does not increment the Page ID and everything works as expected. I have a quickstart app that illustrates the problem. Here is the page with the applicable code: http://pastebin.com/jn9czHK8 Mark On Friday, December 9, 2011 at 9:56 AM, Nazaret Kazarian wrote: Which version of Wicket are you using? 2011/12/7 Lichtenberg, Mark mlichtenb...@machenergy.com (mailto:mlichtenb...@machenergy.com) (mailto: mlichtenb...@machenergy.com (mailto:mlichtenb...@machenergy.com)): I have a page containing a number of AjaxLinks that when clicked fetch data and update some panels. When a user leaves one of these pages and returns via the back button the state of the page isn't always how they left it. However, this behavior happens only when the page is returned to the second time. Using the the request logger I've been able to partially explain this with the page IDs: 1. First visit to page X has a page ID of 3 2. AjaxLink requests for this page also have a page ID of 3. 3. User leaves page then returns to page X via the back button; this request also has ID of 3 4. User clicks AjaxLinks again, but here a new X page is created with an ID of 5 5. User leaves page and again returns with the back button. Here the page state is as they left it in #2, and the URL confirms the page ID of 3 I understand using the back button will always take the user to ID 3 since it is present in the URL. My workaround so far is to add the Page component to the target of my AjaxLink onClick()s. This increments the page ID whenever an AjaxLink is clicked and is reflected in the URL, so the back button always returns to the last state. So I have two questions - Why is a new page X created in step 4 above, and why does adding the Page component to the ajax request target make a new page map entry? Thanks, Mark - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org (mailto:users-unsubscr...@wicket.apache.org) (mailto: users-unsubscr...@wicket.apache.org (mailto:users-unsubscr...@wicket.apache.org)) For additional commands, e-mail: users-h...@wicket.apache.org (mailto:users-h...@wicket.apache.org) (mailto: users-h...@wicket.apache.org (mailto:users-h...@wicket.apache.org))
Re: Page Map versions and Ajax Requests
I'm seeing requests logged when the RequestLogger is enabled during page reloads and when the back button is used. The same code under 1.4 does not. I assumed the extra request was to fetch the latest render of the page if it was updated via ajax. On Friday, December 9, 2011 at 1:59 PM, Dan Retzlaff wrote: I wouldn't say there are extra requests, just extra page versions due to re-population of the list view. Seems like the re-population process should be engineered in a way that doesn't advance the page number. But I'll leave that to the experts. :) On Fri, Dec 9, 2011 at 11:50 AM, Mark Lichtenberg mlichtenb...@machenergy.com (mailto:mlichtenb...@machenergy.com) wrote: That's exactly what I'm experiencing. In 1.5 it appears there's a few extra requests during a reload that I assume are retrieving the latest page version. I'll create a bug report. Thanks for your help. Mark On Friday, December 9, 2011 at 1:26 PM, Dan Retzlaff wrote: I confirmed this behavior in our application. Simply reloading a page with a ListView a few times advances the page ID but not the URL. AJAX links know to target the new page ID, but any updates they make get lost if the page gets reloaded from the URL. Sounds like a bug to me. Wicket 1.4 didn't behave this way. On Fri, Dec 9, 2011 at 10:26 AM, Dan Retzlaff dretzl...@gmail.com (mailto:dretzl...@gmail.com)(mailto: dretzl...@gmail.com (mailto:dretzl...@gmail.com)) wrote: Without reusing the ListView items, the item.add(...) will get called with each render. I expect that'll cause MarkupContainer#addedComponent() to WebPage#componentAdded() to WebPage#dirty() which sets a new page ID. Sorry I don't have time to test the theory at the moment. On Fri, Dec 9, 2011 at 8:27 AM, Mark Lichtenberg mlichtenb...@machenergy.com (mailto:mlichtenb...@machenergy.com) wrote: 1.5.3. I've narrowed the problem to a ListView being present on the page. Whenever there's a ListView with setReuseItems set to false (the default) the Page ID gets incremented whenever the back button is used to return to the page. I confirmed this with a call to getPage().getPageId() in an onComponentTag method. After returning via the back button the URL is still at the original Page ID while there's a newer version in the page map. Without a ListView present on the page using the back button does not increment the Page ID and everything works as expected. I have a quickstart app that illustrates the problem. Here is the page with the applicable code: http://pastebin.com/jn9czHK8 Mark On Friday, December 9, 2011 at 9:56 AM, Nazaret Kazarian wrote: Which version of Wicket are you using? 2011/12/7 Lichtenberg, Mark mlichtenb...@machenergy.com (mailto:mlichtenb...@machenergy.com) (mailto: mlichtenb...@machenergy.com (mailto:mlichtenb...@machenergy.com)) (mailto: mlichtenb...@machenergy.com (mailto:mlichtenb...@machenergy.com)): I have a page containing a number of AjaxLinks that when clicked fetch data and update some panels. When a user leaves one of these pages and returns via the back button the state of the page isn't always how they left it. However, this behavior happens only when the page is returned to the second time. Using the the request logger I've been able to partially explain this with the page IDs: 1. First visit to page X has a page ID of 3 2. AjaxLink requests for this page also have a page ID of 3. 3. User leaves page then returns to page X via the back button; this request also has ID of 3 4. User clicks AjaxLinks again, but here a new X page is created with an ID of 5 5. User leaves page and again returns with the back button. Here the page state is as they left it in #2, and the URL confirms the page ID of 3 I understand using the back button will always take the user to ID 3 since it is present in the URL. My workaround so far is to add the Page component to the target of my AjaxLink onClick()s. This increments the page ID whenever an AjaxLink is clicked and is reflected in the URL, so the back button always returns
Page Map versions and Ajax Requests
I have a page containing a number of AjaxLinks that when clicked fetch data and update some panels. When a user leaves one of these pages and returns via the back button the state of the page isn't always how they left it. However, this behavior happens only when the page is returned to the second time. Using the the request logger I've been able to partially explain this with the page IDs: First visit to page X has a page ID of 3 AjaxLink requests for this page also have a page ID of 3. User leaves page then returns to page X via the back button; this request also has ID of 3 User clicks AjaxLinks again, but here a new X page is created with an ID of 5 User leaves page and again returns with the back button. Here the page state is as they left it in #2, and the URL confirms the page ID of 3 I understand using the back button will always take the user to ID 3 since it is present in the URL. My workaround so far is to add the Page component to the target of my AjaxLink onClick()s. This increments the page ID whenever an AjaxLink is clicked and is reflected in the URL, so the back button always returns to the last state. So I have two questions - Why is a new page X created in step 4 above, and why does adding the Page component to the ajax request target make a new page map entry? Thanks, Mark
Re: Detect LoginPage redirection with swarm
That worked perfectly. Thanks!
Mark
On [Jun 10], at 2:59 AM, Maurice Marrink wrote:
It should be fairly simple to show a message on the login page stating
the user will be redirected to whichever page they were trying to
visit.
It would be a lot more difficult i think to show a warning prior to
redirecting to the login paging. But as i understand it that is
fortunately not what you want :)
Swarm uses ISecurityChecks to solve authorization and authentication,
only a few checks should ever have to worry about redirecting to the
login page. The most prominent place this happens is during the
instantiation check in the ClassSecurityCheck By default this is used
on every page implementing ISecurePage interface. The interface is
customizable but it is also possible to override this per page.
So what you could do is extend ClassSecurityCheck to store the page in
the session you came from and then in the login page check for that
and display an appropriate message. There might be other ways but i am
not aware of them. :)
public class LoggingClasssecurityCheck extends ClassSecurityCheck
{
public boolean isActionAuthorized(WaspAction action)
{
if (getClazz() == getLoginPage())
return true;
if (isAuthenticated())
return getStrategy().isClassAuthorized(getClazz(),
action);
//not authenticated, log and redirect
((MySession)Session.get()).logRedirect(getClazz());
throw new
RestartResponseAtInterceptPageException(getLoginPage());
}
}
To use this check instead of the default just add a static final field
containing an instance of the check to your page. The entire class
hierarchy is searched so you could put it on your basepage to affect
every page. If multiple static final fields containing ISecurityChecks
are found in a class hierarchy all of them have to validate. Ofcourse
annotations would be much nicer for this but swarm is still using java
1.4.
Maurice
On Tue, Jun 10, 2008 at 12:08 AM, Mark Lichtenberg
[EMAIL PROTECTED] wrote:
Hi - We have a fairly straightforward app in which each page extends
SecureWebPage such that if a user attempts to directly land on a
mounted
page, they will be redirected to our login page (as supplied in our
Application.getLoginpage() method). After logging in, the user is
directed
to the originally requested page.
We have a requirement to alert a user that they will be redirected
on the
login page - but I can not find a way to detect this in our Login
page
class. I've tried getRequestCycle().isRedirect(), but this returns
false
whether the page is loaded directly or as an intercept page. Anyone
know how
I should approach this? Thanks.
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Detect LoginPage redirection with swarm
Hi - We have a fairly straightforward app in which each page extends SecureWebPage such that if a user attempts to directly land on a mounted page, they will be redirected to our login page (as supplied in our Application.getLoginpage() method). After logging in, the user is directed to the originally requested page. We have a requirement to alert a user that they will be redirected on the login page - but I can not find a way to detect this in our Login page class. I've tried getRequestCycle().isRedirect(), but this returns false whether the page is loaded directly or as an intercept page. Anyone know how I should approach this? Thanks. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
StackOverflowError using 1.3.2
Hi, We've been experiencing StackOverflowErrors when our application is under a load of around 4 sessions, mostly clicks to load pages without necessarily waiting for the previous click to finish. I saw this was addressed with jira issue 1365, and was part of 1.3.2, which we are using. For good measure, we took out all instance variables referencing Page objects, which was mentioned in the jira issue, but this did not help either. We also tried the wicket nightly today, but got the same results. Seems to be due to page deserialization - a snippet of the exception is below. Any help would be greatly appreciated. 11:15:15,497 ERROR [[default]] Servlet.service() for servlet default threw exception java.lang.StackOverflowError at java.io.ObjectInputStream $PeekInputStream.read(ObjectInputStream.java:2213) at java.io.ObjectInputStream $PeekInputStream.readFully(ObjectInputStream.java:2226) at java.io.ObjectInputStream $BlockDataInputStream.readUTFBody(ObjectInputStream.java:2963) at java.io.ObjectInputStream $BlockDataInputStream.readUTF(ObjectInputStream.java:2764) at java.io.ObjectInputStream.readUTF(ObjectInputStream.java:1032) at java.io.ObjectStreamClass.readNonProxy(ObjectStreamClass.java:600) at java.io.ObjectInputStream.readClassDescriptor(ObjectInputStream.java: 789) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java: 1534) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1699) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at java.util.HashSet.readObject(HashSet.java:278) at sun.reflect.GeneratedMethodAccessor121.invoke(Unknown Source) at sun .reflect .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:585) at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java: 946) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: 1809) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1719) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java: 1908) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: 1832) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1719) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at java.util.HashMap.readObject(HashMap.java:1067) at sun.reflect.GeneratedMethodAccessor122.invoke(Unknown Source) at sun .reflect .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) at java.lang.reflect.Method.invoke(Method.java:585) at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java: 946) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java: 1809) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1719) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java: 1719) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at org.apache.wicket.util.lang.Objects.byteArrayToObject(Objects.java: 392) at org .apache .wicket .protocol .http .pagestore.AbstractPageStore.deserializePage(AbstractPageStore.java:228) at org .apache .wicket .protocol.http.pagestore.DiskPageStore.getPage(DiskPageStore.java:706) at org.apache.wicket.protocol.http.SecondLevelCacheSessionStore $SecondLevelCachePageMap.get(SecondLevelCacheSessionStore.java:311) at org.apache.wicket.Session.getPage(Session.java:751) at org.apache.wicket.protocol.http.pagestore.AbstractPageStore $PageHolder.readResolve(AbstractPageStore.java:363) at sun.reflect.GeneratedMethodAccessor136.invoke(Unknown Source) at sun .reflect .DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 25) .. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
