You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Mikko Pukki (JIRA)" <ji...@apache.org> on 2008/12/08 13:14:44 UTC
[jira] Created: (WICKET-1971) AjaxSelfUpdatingBehavior problem with
HttpSessionStore
AjaxSelfUpdatingBehavior problem with HttpSessionStore
------------------------------------------------------
Key: WICKET-1971
URL: https://issues.apache.org/jira/browse/WICKET-1971
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.5
Reporter: Mikko Pukki
Issue is discussed at:
http://www.nabble.com/AjaxSelfUpdatingBehavior-problem-with-HttpSessionStore-to20841818.html#a20842209
We discovered a problem when using AjaxSelfUpdatingbehavior combined
with ajax buttons (when ajax button forwards to another page (let's call is PageB) by
setResponsePage method).
When a user hits a button and immediately after that an ajax request is fired by the
AjaxSelfUpdatingbehavior, AccessStackPageMap thinks that user has pressed back button.
This is what happens when this behavior occurs:
1) User pressed an ajax button
2) AjaxSelUpdatingBehavior fires another ajax request right after user pressed button
3) User ends up on PageB
4) now pressing ajax buttons on a new page has no effect
WebRequestCycleProcessor's resolve method goes now to line 114:
if (pageId != access.getId())
{
// the page is no longer the active page
// - ignore this request
processRequest = false;
}
Wicket Ajax Debug prints something like this:
INFO: Initiating Ajax POST request on ? wicket:interface=:1:inputForm:back::IActivePageBehaviorListener:0:&wicket:ignoreIfNotActive=true&random=0.6741350924814413
INFO: Invoking pre-call handler(s)...
INFO: Received ajax response (31 characters)
INFO:
<ajax-response></ajax-response>
ERROR: Error while parsing response: Could not find root <ajax-response> element
INFO: Invoking post-call handler(s)...
We debugged around a bit and discovered that when this behavior happens, AccessStackPageMap's
accept method is called with instance of PageB as entry parameter. But instantly after that a request
that came from AjaxSelfUpdatingBehavior calls also AccessStackPageMap's
accept method (entry is now the page where AjaxSelfUpdatingBehavior was added). Now reference
of PageB is removed from stack and AccessStackPagemap thinks that user is on previous page while user
is really on PageB.
I made simplest possible quickstart application that behaves like this. I put an AjaxSelfUpdatingBehavior to
update a component on a page at 2 second intervals. Then I added an Ajax link and in its onSubmit method I
put thread to sleep for 3 seconds before setResponsePage is called. That way this behavior can be repeated
always when pressing the button. If the sleep is removed then of course this happens rarely, but in our real
life application it shows up very frequently.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1971) AjaxSelfUpdatingBehavior problem
with HttpSessionStore
Posted by "Henk Leermakers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654757#action_12654757 ]
Henk Leermakers commented on WICKET-1971:
-----------------------------------------
I agree this is a serious issue and should be fixed with high priority ! Users of applications suffering with this problem are getting frustrated. Submit's will end with "page expired" or alternatively ajax processes just don't do anything.
> AjaxSelfUpdatingBehavior problem with HttpSessionStore
> ------------------------------------------------------
>
> Key: WICKET-1971
> URL: https://issues.apache.org/jira/browse/WICKET-1971
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.3.5
> Reporter: Mikko Pukki
> Attachments: ajaxSelfUpdateTest.zip
>
>
> Issue is discussed at:
> http://www.nabble.com/AjaxSelfUpdatingBehavior-problem-with-HttpSessionStore-to20841818.html#a20842209
> We discovered a problem when using AjaxSelfUpdatingbehavior combined
> with ajax buttons (when ajax button forwards to another page (let's call is PageB) by
> setResponsePage method).
> When a user hits a button and immediately after that an ajax request is fired by the
> AjaxSelfUpdatingbehavior, AccessStackPageMap thinks that user has pressed back button.
> This is what happens when this behavior occurs:
> 1) User pressed an ajax button
> 2) AjaxSelUpdatingBehavior fires another ajax request right after user pressed button
> 3) User ends up on PageB
> 4) now pressing ajax buttons on a new page has no effect
> WebRequestCycleProcessor's resolve method goes now to line 114:
> if (pageId != access.getId())
> {
> // the page is no longer the active page
> // - ignore this request
> processRequest = false;
> }
> Wicket Ajax Debug prints something like this:
> INFO: Initiating Ajax POST request on ? wicket:interface=:1:inputForm:back::IActivePageBehaviorListener:0:&wicket:ignoreIfNotActive=true&random=0.6741350924814413
> INFO: Invoking pre-call handler(s)...
> INFO: Received ajax response (31 characters)
> INFO:
> <ajax-response></ajax-response>
> ERROR: Error while parsing response: Could not find root <ajax-response> element
> INFO: Invoking post-call handler(s)...
> We debugged around a bit and discovered that when this behavior happens, AccessStackPageMap's
> accept method is called with instance of PageB as entry parameter. But instantly after that a request
> that came from AjaxSelfUpdatingBehavior calls also AccessStackPageMap's
> accept method (entry is now the page where AjaxSelfUpdatingBehavior was added). Now reference
> of PageB is removed from stack and AccessStackPagemap thinks that user is on previous page while user
> is really on PageB.
> I made simplest possible quickstart application that behaves like this. I put an AjaxSelfUpdatingBehavior to
> update a component on a page at 2 second intervals. Then I added an Ajax link and in its onSubmit method I
> put thread to sleep for 3 seconds before setResponsePage is called. That way this behavior can be repeated
> always when pressing the button. If the sleep is removed then of course this happens rarely, but in our real
> life application it shows up very frequently.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1971) AjaxSelfUpdatingBehavior problem
with HttpSessionStore
Posted by "Johan Compagner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12656731#action_12656731 ]
Johan Compagner commented on WICKET-1971:
-----------------------------------------
we will look at it, but it is not that high prio because the normal httpsessionstore is kind off "depricated" for 1.3+
HttpSessionStore is very hard to get it really working completely correct in all situations.
> AjaxSelfUpdatingBehavior problem with HttpSessionStore
> ------------------------------------------------------
>
> Key: WICKET-1971
> URL: https://issues.apache.org/jira/browse/WICKET-1971
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.3.5
> Reporter: Mikko Pukki
> Assignee: Matej Knopp
> Attachments: ajaxSelfUpdateTest.zip
>
>
> Issue is discussed at:
> http://www.nabble.com/AjaxSelfUpdatingBehavior-problem-with-HttpSessionStore-to20841818.html#a20842209
> We discovered a problem when using AjaxSelfUpdatingbehavior combined
> with ajax buttons (when ajax button forwards to another page (let's call is PageB) by
> setResponsePage method).
> When a user hits a button and immediately after that an ajax request is fired by the
> AjaxSelfUpdatingbehavior, AccessStackPageMap thinks that user has pressed back button.
> This is what happens when this behavior occurs:
> 1) User pressed an ajax button
> 2) AjaxSelUpdatingBehavior fires another ajax request right after user pressed button
> 3) User ends up on PageB
> 4) now pressing ajax buttons on a new page has no effect
> WebRequestCycleProcessor's resolve method goes now to line 114:
> if (pageId != access.getId())
> {
> // the page is no longer the active page
> // - ignore this request
> processRequest = false;
> }
> Wicket Ajax Debug prints something like this:
> INFO: Initiating Ajax POST request on ? wicket:interface=:1:inputForm:back::IActivePageBehaviorListener:0:&wicket:ignoreIfNotActive=true&random=0.6741350924814413
> INFO: Invoking pre-call handler(s)...
> INFO: Received ajax response (31 characters)
> INFO:
> <ajax-response></ajax-response>
> ERROR: Error while parsing response: Could not find root <ajax-response> element
> INFO: Invoking post-call handler(s)...
> We debugged around a bit and discovered that when this behavior happens, AccessStackPageMap's
> accept method is called with instance of PageB as entry parameter. But instantly after that a request
> that came from AjaxSelfUpdatingBehavior calls also AccessStackPageMap's
> accept method (entry is now the page where AjaxSelfUpdatingBehavior was added). Now reference
> of PageB is removed from stack and AccessStackPagemap thinks that user is on previous page while user
> is really on PageB.
> I made simplest possible quickstart application that behaves like this. I put an AjaxSelfUpdatingBehavior to
> update a component on a page at 2 second intervals. Then I added an Ajax link and in its onSubmit method I
> put thread to sleep for 3 seconds before setResponsePage is called. That way this behavior can be repeated
> always when pressing the button. If the sleep is removed then of course this happens rarely, but in our real
> life application it shows up very frequently.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1971) AjaxSelfUpdatingBehavior problem with
HttpSessionStore
Posted by "Mikko Pukki (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mikko Pukki updated WICKET-1971:
--------------------------------
Attachment: ajaxSelfUpdateTest.zip
Attached quickstart application to issue
> AjaxSelfUpdatingBehavior problem with HttpSessionStore
> ------------------------------------------------------
>
> Key: WICKET-1971
> URL: https://issues.apache.org/jira/browse/WICKET-1971
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.3.5
> Reporter: Mikko Pukki
> Attachments: ajaxSelfUpdateTest.zip
>
>
> Issue is discussed at:
> http://www.nabble.com/AjaxSelfUpdatingBehavior-problem-with-HttpSessionStore-to20841818.html#a20842209
> We discovered a problem when using AjaxSelfUpdatingbehavior combined
> with ajax buttons (when ajax button forwards to another page (let's call is PageB) by
> setResponsePage method).
> When a user hits a button and immediately after that an ajax request is fired by the
> AjaxSelfUpdatingbehavior, AccessStackPageMap thinks that user has pressed back button.
> This is what happens when this behavior occurs:
> 1) User pressed an ajax button
> 2) AjaxSelUpdatingBehavior fires another ajax request right after user pressed button
> 3) User ends up on PageB
> 4) now pressing ajax buttons on a new page has no effect
> WebRequestCycleProcessor's resolve method goes now to line 114:
> if (pageId != access.getId())
> {
> // the page is no longer the active page
> // - ignore this request
> processRequest = false;
> }
> Wicket Ajax Debug prints something like this:
> INFO: Initiating Ajax POST request on ? wicket:interface=:1:inputForm:back::IActivePageBehaviorListener:0:&wicket:ignoreIfNotActive=true&random=0.6741350924814413
> INFO: Invoking pre-call handler(s)...
> INFO: Received ajax response (31 characters)
> INFO:
> <ajax-response></ajax-response>
> ERROR: Error while parsing response: Could not find root <ajax-response> element
> INFO: Invoking post-call handler(s)...
> We debugged around a bit and discovered that when this behavior happens, AccessStackPageMap's
> accept method is called with instance of PageB as entry parameter. But instantly after that a request
> that came from AjaxSelfUpdatingBehavior calls also AccessStackPageMap's
> accept method (entry is now the page where AjaxSelfUpdatingBehavior was added). Now reference
> of PageB is removed from stack and AccessStackPagemap thinks that user is on previous page while user
> is really on PageB.
> I made simplest possible quickstart application that behaves like this. I put an AjaxSelfUpdatingBehavior to
> update a component on a page at 2 second intervals. Then I added an Ajax link and in its onSubmit method I
> put thread to sleep for 3 seconds before setResponsePage is called. That way this behavior can be repeated
> always when pressing the button. If the sleep is removed then of course this happens rarely, but in our real
> life application it shows up very frequently.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (WICKET-1971) AjaxSelfUpdatingBehavior
problem with HttpSessionStore
Posted by "Mikko Pukki (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654415#action_12654415 ]
mpukki edited comment on WICKET-1971 at 12/8/08 9:52 AM:
--------------------------------------------------------------
Co-worker of mine noticed that when request from AjaxSelfUpdatingBehavior is decoded in class WebRequestCodingStrategy,
"if" -clause on line 202 is not entered.
if (request.getParameter(IGNORE_IF_NOT_ACTIVE_PARAMETER_NAME) != null)
{
parameters.setOnlyProcessIfPathActive(true);
}
Map that is retrieved from request on line 207: "Map map = request.getParameterMap();"
holds key: "amp;wicket:ignoreIfNotActive". I quess that it should contain "wicket:ignoreIfNotActive".
I tested by replacing line 202 with: if (request.getParameter(IGNORE_IF_NOT_ACTIVE_PARAMETER_NAME) != null || request.getParameter("amp;" + IGNORE_IF_NOT_ACTIVE_PARAMETER_NAME) != null)
Then it worked..
I also noticed strange behavior with testing Jetty Server. If I open the HomePage second time with the same browser, then the quickstart runs fine.
was (Author: mpukki):
Co-worker of mine noticed that when request from AjaxSelfUpdatingBehavior is decoded in class WebRequestCodingStrategy,
if clause on line 202 is not executed.
if (request.getParameter(IGNORE_IF_NOT_ACTIVE_PARAMETER_NAME) != null)
{
parameters.setOnlyProcessIfPathActive(true);
}
Map that is retrieved from request on line 207: "Map map = request.getParameterMap();"
holds key: "amp;wicket:ignoreIfNotActive". I quess that it should contain "wicket:ignoreIfNotActive".
I tested by replacing line 202 with: if (request.getParameter(IGNORE_IF_NOT_ACTIVE_PARAMETER_NAME) != null || request.getParameter("amp;" + IGNORE_IF_NOT_ACTIVE_PARAMETER_NAME) != null)
Then it worked..
I also noticed strange behavior with testing Jetty Server. If I open the HomePage second time with the same browser, then the quickstart runs fine.
> AjaxSelfUpdatingBehavior problem with HttpSessionStore
> ------------------------------------------------------
>
> Key: WICKET-1971
> URL: https://issues.apache.org/jira/browse/WICKET-1971
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.3.5
> Reporter: Mikko Pukki
> Attachments: ajaxSelfUpdateTest.zip
>
>
> Issue is discussed at:
> http://www.nabble.com/AjaxSelfUpdatingBehavior-problem-with-HttpSessionStore-to20841818.html#a20842209
> We discovered a problem when using AjaxSelfUpdatingbehavior combined
> with ajax buttons (when ajax button forwards to another page (let's call is PageB) by
> setResponsePage method).
> When a user hits a button and immediately after that an ajax request is fired by the
> AjaxSelfUpdatingbehavior, AccessStackPageMap thinks that user has pressed back button.
> This is what happens when this behavior occurs:
> 1) User pressed an ajax button
> 2) AjaxSelUpdatingBehavior fires another ajax request right after user pressed button
> 3) User ends up on PageB
> 4) now pressing ajax buttons on a new page has no effect
> WebRequestCycleProcessor's resolve method goes now to line 114:
> if (pageId != access.getId())
> {
> // the page is no longer the active page
> // - ignore this request
> processRequest = false;
> }
> Wicket Ajax Debug prints something like this:
> INFO: Initiating Ajax POST request on ? wicket:interface=:1:inputForm:back::IActivePageBehaviorListener:0:&wicket:ignoreIfNotActive=true&random=0.6741350924814413
> INFO: Invoking pre-call handler(s)...
> INFO: Received ajax response (31 characters)
> INFO:
> <ajax-response></ajax-response>
> ERROR: Error while parsing response: Could not find root <ajax-response> element
> INFO: Invoking post-call handler(s)...
> We debugged around a bit and discovered that when this behavior happens, AccessStackPageMap's
> accept method is called with instance of PageB as entry parameter. But instantly after that a request
> that came from AjaxSelfUpdatingBehavior calls also AccessStackPageMap's
> accept method (entry is now the page where AjaxSelfUpdatingBehavior was added). Now reference
> of PageB is removed from stack and AccessStackPagemap thinks that user is on previous page while user
> is really on PageB.
> I made simplest possible quickstart application that behaves like this. I put an AjaxSelfUpdatingBehavior to
> update a component on a page at 2 second intervals. Then I added an Ajax link and in its onSubmit method I
> put thread to sleep for 3 seconds before setResponsePage is called. That way this behavior can be repeated
> always when pressing the button. If the sleep is removed then of course this happens rarely, but in our real
> life application it shows up very frequently.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1971) AjaxSelfUpdatingBehavior problem
with HttpSessionStore
Posted by "Mikko Pukki (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654415#action_12654415 ]
Mikko Pukki commented on WICKET-1971:
-------------------------------------
Co-worker of mine noticed that when request from AjaxSelfUpdatingBehavior is decoded in class WebRequestCodingStrategy,
if clause on line 202 is not executed.
if (request.getParameter(IGNORE_IF_NOT_ACTIVE_PARAMETER_NAME) != null)
{
parameters.setOnlyProcessIfPathActive(true);
}
Map that is retrieved from request on line 207: "Map map = request.getParameterMap();"
holds key: "amp;wicket:ignoreIfNotActive". I quess that it should contain "wicket:ignoreIfNotActive".
I tested by replacing line 202 with: if (request.getParameter(IGNORE_IF_NOT_ACTIVE_PARAMETER_NAME) != null || request.getParameter("amp;" + IGNORE_IF_NOT_ACTIVE_PARAMETER_NAME) != null)
Then it worked..
I also noticed strange behavior with testing Jetty Server. If I open the HomePage second time with the same browser, then the quickstart runs fine.
> AjaxSelfUpdatingBehavior problem with HttpSessionStore
> ------------------------------------------------------
>
> Key: WICKET-1971
> URL: https://issues.apache.org/jira/browse/WICKET-1971
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.3.5
> Reporter: Mikko Pukki
> Attachments: ajaxSelfUpdateTest.zip
>
>
> Issue is discussed at:
> http://www.nabble.com/AjaxSelfUpdatingBehavior-problem-with-HttpSessionStore-to20841818.html#a20842209
> We discovered a problem when using AjaxSelfUpdatingbehavior combined
> with ajax buttons (when ajax button forwards to another page (let's call is PageB) by
> setResponsePage method).
> When a user hits a button and immediately after that an ajax request is fired by the
> AjaxSelfUpdatingbehavior, AccessStackPageMap thinks that user has pressed back button.
> This is what happens when this behavior occurs:
> 1) User pressed an ajax button
> 2) AjaxSelUpdatingBehavior fires another ajax request right after user pressed button
> 3) User ends up on PageB
> 4) now pressing ajax buttons on a new page has no effect
> WebRequestCycleProcessor's resolve method goes now to line 114:
> if (pageId != access.getId())
> {
> // the page is no longer the active page
> // - ignore this request
> processRequest = false;
> }
> Wicket Ajax Debug prints something like this:
> INFO: Initiating Ajax POST request on ? wicket:interface=:1:inputForm:back::IActivePageBehaviorListener:0:&wicket:ignoreIfNotActive=true&random=0.6741350924814413
> INFO: Invoking pre-call handler(s)...
> INFO: Received ajax response (31 characters)
> INFO:
> <ajax-response></ajax-response>
> ERROR: Error while parsing response: Could not find root <ajax-response> element
> INFO: Invoking post-call handler(s)...
> We debugged around a bit and discovered that when this behavior happens, AccessStackPageMap's
> accept method is called with instance of PageB as entry parameter. But instantly after that a request
> that came from AjaxSelfUpdatingBehavior calls also AccessStackPageMap's
> accept method (entry is now the page where AjaxSelfUpdatingBehavior was added). Now reference
> of PageB is removed from stack and AccessStackPagemap thinks that user is on previous page while user
> is really on PageB.
> I made simplest possible quickstart application that behaves like this. I put an AjaxSelfUpdatingBehavior to
> update a component on a page at 2 second intervals. Then I added an Ajax link and in its onSubmit method I
> put thread to sleep for 3 seconds before setResponsePage is called. That way this behavior can be repeated
> always when pressing the button. If the sleep is removed then of course this happens rarely, but in our real
> life application it shows up very frequently.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (WICKET-1971) AjaxSelfUpdatingBehavior problem
with HttpSessionStore
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Vaynberg reassigned WICKET-1971:
-------------------------------------
Assignee: Matej Knopp
> AjaxSelfUpdatingBehavior problem with HttpSessionStore
> ------------------------------------------------------
>
> Key: WICKET-1971
> URL: https://issues.apache.org/jira/browse/WICKET-1971
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.3.5
> Reporter: Mikko Pukki
> Assignee: Matej Knopp
> Attachments: ajaxSelfUpdateTest.zip
>
>
> Issue is discussed at:
> http://www.nabble.com/AjaxSelfUpdatingBehavior-problem-with-HttpSessionStore-to20841818.html#a20842209
> We discovered a problem when using AjaxSelfUpdatingbehavior combined
> with ajax buttons (when ajax button forwards to another page (let's call is PageB) by
> setResponsePage method).
> When a user hits a button and immediately after that an ajax request is fired by the
> AjaxSelfUpdatingbehavior, AccessStackPageMap thinks that user has pressed back button.
> This is what happens when this behavior occurs:
> 1) User pressed an ajax button
> 2) AjaxSelUpdatingBehavior fires another ajax request right after user pressed button
> 3) User ends up on PageB
> 4) now pressing ajax buttons on a new page has no effect
> WebRequestCycleProcessor's resolve method goes now to line 114:
> if (pageId != access.getId())
> {
> // the page is no longer the active page
> // - ignore this request
> processRequest = false;
> }
> Wicket Ajax Debug prints something like this:
> INFO: Initiating Ajax POST request on ? wicket:interface=:1:inputForm:back::IActivePageBehaviorListener:0:&wicket:ignoreIfNotActive=true&random=0.6741350924814413
> INFO: Invoking pre-call handler(s)...
> INFO: Received ajax response (31 characters)
> INFO:
> <ajax-response></ajax-response>
> ERROR: Error while parsing response: Could not find root <ajax-response> element
> INFO: Invoking post-call handler(s)...
> We debugged around a bit and discovered that when this behavior happens, AccessStackPageMap's
> accept method is called with instance of PageB as entry parameter. But instantly after that a request
> that came from AjaxSelfUpdatingBehavior calls also AccessStackPageMap's
> accept method (entry is now the page where AjaxSelfUpdatingBehavior was added). Now reference
> of PageB is removed from stack and AccessStackPagemap thinks that user is on previous page while user
> is really on PageB.
> I made simplest possible quickstart application that behaves like this. I put an AjaxSelfUpdatingBehavior to
> update a component on a page at 2 second intervals. Then I added an Ajax link and in its onSubmit method I
> put thread to sleep for 3 seconds before setResponsePage is called. That way this behavior can be repeated
> always when pressing the button. If the sleep is removed then of course this happens rarely, but in our real
> life application it shows up very frequently.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1971) AjaxSelfUpdatingBehavior problem
with HttpSessionStore
Posted by "Jani Väisänen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12656629#action_12656629 ]
Jani Väisänen commented on WICKET-1971:
---------------------------------------
Is this possible workaround or could this break anything:
If we alter the function initialize in the wicket-ajax.js, our case seems to work.
If you replace this line:
this.url = url;
with this one:
this.url = Wicket.replaceAll(url,"&", "&");
Wicket.Ajax.Request.prototype = {
// Creates a new request object.
initialize: function(url, loadedCallback, parseResponse, randomURL, failureHandler, channel) {
this.url = Wicket.replaceAll(url,"&", "&");
this.loadedCallback = loadedCallback;
// whether we should give the loadedCallback parsed response (DOM tree) or the raw string
this.parseResponse = parseResponse != null ? parseResponse : true;
this.randomURL = randomURL != null ? randomURL : true;
this.failureHandler = failureHandler != null ? failureHandler : function() { };
this.async = true;
this.channel = channel;
this.precondition = function() { return true; } // allow a condition to block request
// when suppressDone is set, the loadedCallback is responsible for calling
// Ajax.Request.done() to process possibly pendings requests in the channel.
this.suppressDone = false;
this.instance = Math.random();
this.debugContent = true;
},
done: function() {
Wicket.channelManager.done(this.channel);
},
> AjaxSelfUpdatingBehavior problem with HttpSessionStore
> ------------------------------------------------------
>
> Key: WICKET-1971
> URL: https://issues.apache.org/jira/browse/WICKET-1971
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.3.5
> Reporter: Mikko Pukki
> Attachments: ajaxSelfUpdateTest.zip
>
>
> Issue is discussed at:
> http://www.nabble.com/AjaxSelfUpdatingBehavior-problem-with-HttpSessionStore-to20841818.html#a20842209
> We discovered a problem when using AjaxSelfUpdatingbehavior combined
> with ajax buttons (when ajax button forwards to another page (let's call is PageB) by
> setResponsePage method).
> When a user hits a button and immediately after that an ajax request is fired by the
> AjaxSelfUpdatingbehavior, AccessStackPageMap thinks that user has pressed back button.
> This is what happens when this behavior occurs:
> 1) User pressed an ajax button
> 2) AjaxSelUpdatingBehavior fires another ajax request right after user pressed button
> 3) User ends up on PageB
> 4) now pressing ajax buttons on a new page has no effect
> WebRequestCycleProcessor's resolve method goes now to line 114:
> if (pageId != access.getId())
> {
> // the page is no longer the active page
> // - ignore this request
> processRequest = false;
> }
> Wicket Ajax Debug prints something like this:
> INFO: Initiating Ajax POST request on ? wicket:interface=:1:inputForm:back::IActivePageBehaviorListener:0:&wicket:ignoreIfNotActive=true&random=0.6741350924814413
> INFO: Invoking pre-call handler(s)...
> INFO: Received ajax response (31 characters)
> INFO:
> <ajax-response></ajax-response>
> ERROR: Error while parsing response: Could not find root <ajax-response> element
> INFO: Invoking post-call handler(s)...
> We debugged around a bit and discovered that when this behavior happens, AccessStackPageMap's
> accept method is called with instance of PageB as entry parameter. But instantly after that a request
> that came from AjaxSelfUpdatingBehavior calls also AccessStackPageMap's
> accept method (entry is now the page where AjaxSelfUpdatingBehavior was added). Now reference
> of PageB is removed from stack and AccessStackPagemap thinks that user is on previous page while user
> is really on PageB.
> I made simplest possible quickstart application that behaves like this. I put an AjaxSelfUpdatingBehavior to
> update a component on a page at 2 second intervals. Then I added an Ajax link and in its onSubmit method I
> put thread to sleep for 3 seconds before setResponsePage is called. That way this behavior can be repeated
> always when pressing the button. If the sleep is removed then of course this happens rarely, but in our real
> life application it shows up very frequently.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1971) AjaxSelfUpdatingBehavior problem with
HttpSessionStore
Posted by "Mikko Pukki (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mikko Pukki updated WICKET-1971:
--------------------------------
Attachment: EmptyAjaxRequestTarget_patch.txt
> AjaxSelfUpdatingBehavior problem with HttpSessionStore
> ------------------------------------------------------
>
> Key: WICKET-1971
> URL: https://issues.apache.org/jira/browse/WICKET-1971
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.3.5
> Reporter: Mikko Pukki
> Assignee: Matej Knopp
> Attachments: ajaxSelfUpdateTest.zip, EmptyAjaxRequestTarget_patch.txt
>
>
> Issue is discussed at:
> http://www.nabble.com/AjaxSelfUpdatingBehavior-problem-with-HttpSessionStore-to20841818.html#a20842209
> We discovered a problem when using AjaxSelfUpdatingbehavior combined
> with ajax buttons (when ajax button forwards to another page (let's call is PageB) by
> setResponsePage method).
> When a user hits a button and immediately after that an ajax request is fired by the
> AjaxSelfUpdatingbehavior, AccessStackPageMap thinks that user has pressed back button.
> This is what happens when this behavior occurs:
> 1) User pressed an ajax button
> 2) AjaxSelUpdatingBehavior fires another ajax request right after user pressed button
> 3) User ends up on PageB
> 4) now pressing ajax buttons on a new page has no effect
> WebRequestCycleProcessor's resolve method goes now to line 114:
> if (pageId != access.getId())
> {
> // the page is no longer the active page
> // - ignore this request
> processRequest = false;
> }
> Wicket Ajax Debug prints something like this:
> INFO: Initiating Ajax POST request on ? wicket:interface=:1:inputForm:back::IActivePageBehaviorListener:0:&wicket:ignoreIfNotActive=true&random=0.6741350924814413
> INFO: Invoking pre-call handler(s)...
> INFO: Received ajax response (31 characters)
> INFO:
> <ajax-response></ajax-response>
> ERROR: Error while parsing response: Could not find root <ajax-response> element
> INFO: Invoking post-call handler(s)...
> We debugged around a bit and discovered that when this behavior happens, AccessStackPageMap's
> accept method is called with instance of PageB as entry parameter. But instantly after that a request
> that came from AjaxSelfUpdatingBehavior calls also AccessStackPageMap's
> accept method (entry is now the page where AjaxSelfUpdatingBehavior was added). Now reference
> of PageB is removed from stack and AccessStackPagemap thinks that user is on previous page while user
> is really on PageB.
> I made simplest possible quickstart application that behaves like this. I put an AjaxSelfUpdatingBehavior to
> update a component on a page at 2 second intervals. Then I added an Ajax link and in its onSubmit method I
> put thread to sleep for 3 seconds before setResponsePage is called. That way this behavior can be repeated
> always when pressing the button. If the sleep is removed then of course this happens rarely, but in our real
> life application it shows up very frequently.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1971) AjaxSelfUpdatingBehavior problem
with HttpSessionStore
Posted by "Igor Vaynberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Vaynberg resolved WICKET-1971.
-----------------------------------
Assignee: Igor Vaynberg (was: Matej Knopp)
Resolution: Cannot Reproduce
cannot repro with 1.4.x
> AjaxSelfUpdatingBehavior problem with HttpSessionStore
> ------------------------------------------------------
>
> Key: WICKET-1971
> URL: https://issues.apache.org/jira/browse/WICKET-1971
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.3.5
> Reporter: Mikko Pukki
> Assignee: Igor Vaynberg
> Attachments: ajaxSelfUpdateTest.zip, EmptyAjaxRequestTarget_patch.txt
>
>
> Issue is discussed at:
> http://www.nabble.com/AjaxSelfUpdatingBehavior-problem-with-HttpSessionStore-to20841818.html#a20842209
> We discovered a problem when using AjaxSelfUpdatingbehavior combined
> with ajax buttons (when ajax button forwards to another page (let's call is PageB) by
> setResponsePage method).
> When a user hits a button and immediately after that an ajax request is fired by the
> AjaxSelfUpdatingbehavior, AccessStackPageMap thinks that user has pressed back button.
> This is what happens when this behavior occurs:
> 1) User pressed an ajax button
> 2) AjaxSelUpdatingBehavior fires another ajax request right after user pressed button
> 3) User ends up on PageB
> 4) now pressing ajax buttons on a new page has no effect
> WebRequestCycleProcessor's resolve method goes now to line 114:
> if (pageId != access.getId())
> {
> // the page is no longer the active page
> // - ignore this request
> processRequest = false;
> }
> Wicket Ajax Debug prints something like this:
> INFO: Initiating Ajax POST request on ? wicket:interface=:1:inputForm:back::IActivePageBehaviorListener:0:&wicket:ignoreIfNotActive=true&random=0.6741350924814413
> INFO: Invoking pre-call handler(s)...
> INFO: Received ajax response (31 characters)
> INFO:
> <ajax-response></ajax-response>
> ERROR: Error while parsing response: Could not find root <ajax-response> element
> INFO: Invoking post-call handler(s)...
> We debugged around a bit and discovered that when this behavior happens, AccessStackPageMap's
> accept method is called with instance of PageB as entry parameter. But instantly after that a request
> that came from AjaxSelfUpdatingBehavior calls also AccessStackPageMap's
> accept method (entry is now the page where AjaxSelfUpdatingBehavior was added). Now reference
> of PageB is removed from stack and AccessStackPagemap thinks that user is on previous page while user
> is really on PageB.
> I made simplest possible quickstart application that behaves like this. I put an AjaxSelfUpdatingBehavior to
> update a component on a page at 2 second intervals. Then I added an Ajax link and in its onSubmit method I
> put thread to sleep for 3 seconds before setResponsePage is called. That way this behavior can be repeated
> always when pressing the button. If the sleep is removed then of course this happens rarely, but in our real
> life application it shows up very frequently.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1971) AjaxSelfUpdatingBehavior problem
with HttpSessionStore
Posted by "Mikko Pukki (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-1971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696935#action_12696935 ]
Mikko Pukki commented on WICKET-1971:
-------------------------------------
Attatched patch.
Just in case here is the code:
public void respond(RequestCycle requestCycle)
{
final WebResponse response = (WebResponse)requestCycle.getResponse();
final Application app = Application.get();
final String encoding = app.getRequestCycleSettings().getResponseRequestEncoding();
// Set content type based on markup type for page
response.setCharacterEncoding(encoding);
response.setContentType("text/xml; charset=" + encoding);
// Make sure it is not cached by a client
response.setHeader("Expires", "Mon, 26 Jul 1997 05:00:00 GMT");
response.setHeader("Cache-Control", "no-cache, must-revalidate");
response.setHeader("Pragma", "no-cache");
response.write("<?xml version=\"1.0\" encoding=\"");
response.write(encoding);
response.write("\"?>");
response.write("<ajax-response></ajax-response>");
}
> AjaxSelfUpdatingBehavior problem with HttpSessionStore
> ------------------------------------------------------
>
> Key: WICKET-1971
> URL: https://issues.apache.org/jira/browse/WICKET-1971
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.3.5
> Reporter: Mikko Pukki
> Assignee: Matej Knopp
> Attachments: ajaxSelfUpdateTest.zip, EmptyAjaxRequestTarget_patch.txt
>
>
> Issue is discussed at:
> http://www.nabble.com/AjaxSelfUpdatingBehavior-problem-with-HttpSessionStore-to20841818.html#a20842209
> We discovered a problem when using AjaxSelfUpdatingbehavior combined
> with ajax buttons (when ajax button forwards to another page (let's call is PageB) by
> setResponsePage method).
> When a user hits a button and immediately after that an ajax request is fired by the
> AjaxSelfUpdatingbehavior, AccessStackPageMap thinks that user has pressed back button.
> This is what happens when this behavior occurs:
> 1) User pressed an ajax button
> 2) AjaxSelUpdatingBehavior fires another ajax request right after user pressed button
> 3) User ends up on PageB
> 4) now pressing ajax buttons on a new page has no effect
> WebRequestCycleProcessor's resolve method goes now to line 114:
> if (pageId != access.getId())
> {
> // the page is no longer the active page
> // - ignore this request
> processRequest = false;
> }
> Wicket Ajax Debug prints something like this:
> INFO: Initiating Ajax POST request on ? wicket:interface=:1:inputForm:back::IActivePageBehaviorListener:0:&wicket:ignoreIfNotActive=true&random=0.6741350924814413
> INFO: Invoking pre-call handler(s)...
> INFO: Received ajax response (31 characters)
> INFO:
> <ajax-response></ajax-response>
> ERROR: Error while parsing response: Could not find root <ajax-response> element
> INFO: Invoking post-call handler(s)...
> We debugged around a bit and discovered that when this behavior happens, AccessStackPageMap's
> accept method is called with instance of PageB as entry parameter. But instantly after that a request
> that came from AjaxSelfUpdatingBehavior calls also AccessStackPageMap's
> accept method (entry is now the page where AjaxSelfUpdatingBehavior was added). Now reference
> of PageB is removed from stack and AccessStackPagemap thinks that user is on previous page while user
> is really on PageB.
> I made simplest possible quickstart application that behaves like this. I put an AjaxSelfUpdatingBehavior to
> update a component on a page at 2 second intervals. Then I added an Ajax link and in its onSubmit method I
> put thread to sleep for 3 seconds before setResponsePage is called. That way this behavior can be repeated
> always when pressing the button. If the sleep is removed then of course this happens rarely, but in our real
> life application it shows up very frequently.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.