[jira] Created: (WICKET-2958) Success handler not called when redirecting with Ajax
Success handler not called when redirecting with Ajax
-
Key: WICKET-2958
URL: https://issues.apache.org/jira/browse/WICKET-2958
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.4.9
Reporter: Louis Letourneau
Attachments: wicket-ajax.patch
We put an ajax indicator on our page. This adds the wicket.show('indicator')
method before the call to wicketAjaxGet.
To the wicketAjaxGet a success and failure handler are attached that call the
wicket.hide methods.
We have a button that redirects to a file, so the page doesn't change. The
browser just pops up a file download dialog. The thing is that the ajax
indicator isn't removed.
There are no calls to successHandler or failureHandler for redirects only for
loadedCalls.
I attached a patch that adds a call to the successHandler after the this.done()
when a redirect is asked for. In most of the cases the successHandler is an
empty function.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2958) Success handler not called when redirecting with Ajax
[
https://issues.apache.org/jira/browse/WICKET-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Louis Letourneau updated WICKET-2958:
-
Attachment: wicket-ajax.patch
The patch to the issue
Success handler not called when redirecting with Ajax
-
Key: WICKET-2958
URL: https://issues.apache.org/jira/browse/WICKET-2958
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.4.9
Reporter: Louis Letourneau
Attachments: wicket-ajax.patch
We put an ajax indicator on our page. This adds the wicket.show('indicator')
method before the call to wicketAjaxGet.
To the wicketAjaxGet a success and failure handler are attached that call the
wicket.hide methods.
We have a button that redirects to a file, so the page doesn't change. The
browser just pops up a file download dialog. The thing is that the ajax
indicator isn't removed.
There are no calls to successHandler or failureHandler for redirects only for
loadedCalls.
I attached a patch that adds a call to the successHandler after the
this.done() when a redirect is asked for. In most of the cases the
successHandler is an empty function.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2917) WebResponse sets a negative Content-Length when length 2G
WebResponse sets a negative Content-Length when length 2G -- Key: WICKET-2917 URL: https://issues.apache.org/jira/browse/WICKET-2917 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4.9, 1.4.5 Reporter: Louis Letourneau When using ResourceStreamRequestTarget + FileResourceStream to send a file 2G, the resulting Content-Length in the header is a large negative value. This is due to a cast between a long and an int. In wicket, all methods dealing with content-length use longs, but the servlet api HttpServletResponse takes in an int, so WebResponse casts the long into an int which causes the problem. The simple work around is to check for 2G lengths and use the addHeader method instead of setContentLength. Attached is an extended WebResponse that fixes the problem. This should probably be applied to WebResponse. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2917) WebResponse sets a negative Content-Length when length 2G
[ https://issues.apache.org/jira/browse/WICKET-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Louis Letourneau updated WICKET-2917: - Attachment: webResponse-contentLength-1.4.9.patch Patch that adds the fix to WebResponse WebResponse sets a negative Content-Length when length 2G -- Key: WICKET-2917 URL: https://issues.apache.org/jira/browse/WICKET-2917 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4.5, 1.4.9 Reporter: Louis Letourneau Attachments: webResponse-contentLength-1.4.9.patch When using ResourceStreamRequestTarget + FileResourceStream to send a file 2G, the resulting Content-Length in the header is a large negative value. This is due to a cast between a long and an int. In wicket, all methods dealing with content-length use longs, but the servlet api HttpServletResponse takes in an int, so WebResponse casts the long into an int which causes the problem. The simple work around is to check for 2G lengths and use the addHeader method instead of setContentLength. Attached is an extended WebResponse that fixes the problem. This should probably be applied to WebResponse. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2917) WebResponse sets a negative Content-Length when length 2G
[ https://issues.apache.org/jira/browse/WICKET-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12879064#action_12879064 ] Louis Letourneau commented on WICKET-2917: -- The patch tests for the length, but it's not necessary I think, you could just use the addHeader all the time instead. WebResponse sets a negative Content-Length when length 2G -- Key: WICKET-2917 URL: https://issues.apache.org/jira/browse/WICKET-2917 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4.5, 1.4.9 Reporter: Louis Letourneau Attachments: webResponse-contentLength-1.4.9.patch When using ResourceStreamRequestTarget + FileResourceStream to send a file 2G, the resulting Content-Length in the header is a large negative value. This is due to a cast between a long and an int. In wicket, all methods dealing with content-length use longs, but the servlet api HttpServletResponse takes in an int, so WebResponse casts the long into an int which causes the problem. The simple work around is to check for 2G lengths and use the addHeader method instead of setContentLength. Attached is an extended WebResponse that fixes the problem. This should probably be applied to WebResponse. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1838) AjaxLink setResponsePage to a stream = queue is not resumed after redirect.
[
https://issues.apache.org/jira/browse/WICKET-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Louis Letourneau updated WICKET-1838:
-
Attachment: wicket-ajax.patch
This patch solves the problem for me.
AjaxLink setResponsePage to a stream = queue is not resumed after redirect.
---
Key: WICKET-1838
URL: https://issues.apache.org/jira/browse/WICKET-1838
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.4
Environment: wicket 1.3.4
tomcat 5.5.16
Reporter: Louis Letourneau
Assignee: Matej Knopp
Attachments: wicket-ajax.patch
When I click on an AjaxLink that does a setResponsePage towards a
ResourceStreamRequestTarget, afetr the download, the links on the page become
non-clickable. In the Ajax debug window I get a 'Channel busy - postponing'.
Details:
I have a page with many AjaxLinks. The links check whether some data is
available. If the data is available it does a setResponsePage towards a
BookmarkablePage that can work with the data.
The Page that handles the data is mounted on a 'custom'
QueryStringUrlCodingStrategy. In 'decode()' the strategy checks if
manipulations are needed. If not the strategy answers with a
ResourceStreamRequestTarget.
So here's the path that causes the error:
onClick-setResponsePage-decode-ResourceStreamRequestTarget
Once a link has been clicked no other links are clickable on the page.
The redirect seems to happen, but only once.
Say there are 3 files to download on the page, I would need to:
click link1 - download the file - refresh the page - click link2 -. etc.
I shouldn't need to refresh the page.
If I don't refresh the page, when I click link2 I'll get 'Channel busy -
postponing'.
AjaxLink Code:
public void onClick(AjaxRequestTarget target)
{
if(file.isOnline()) {
PageParameters params = new PageParameters();
params.add(id, String.valueOf(typeId));
params.add(type, type.toString());
setResponsePage(StageableFilePage.class, params);
}
else {
modal.show(target);
}
}
QueryStringUrlCodingStrategy Code:
public IRequestTarget decode(RequestParameters requestParameters) {
[..get id and fileType and make sure the user has priviledges..]
final StageableFile file = resolveFile(id, fileType);
if(file.isOnline()) {
IResourceStream resourceStream = new FileResourceStream(file);
//Content-type will be set by the ResourceStreamRequestTarget
ResourceStreamRequestTarget rsrt = new
ResourceStreamRequestTarget(resourceStream) {
@Override
public String getFileName() {
return file.getName();
}
};
return rsrt;
}
else {
return super.decode(requestParameters);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1838) AjaxLink setResponsePage to a stream = queue is not resumed after redirect.
AjaxLink setResponsePage to a stream = queue is not resumed after redirect.
---
Key: WICKET-1838
URL: https://issues.apache.org/jira/browse/WICKET-1838
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.4
Environment: wicket 1.3.4
tomcat 5.5.16
Reporter: Louis Letourneau
When I click on an AjaxLink that does a setResponsePage towards a
ResourceStreamRequestTarget, afetr the download, the links on the page become
non-clickable. In the Ajax debug window I get a 'Channel busy - postponing'.
Details:
I have a page with many AjaxLinks. The links check whether some data is
available. If the data is available it does a setResponsePage towards a
BookmarkablePage that can work with the data.
The Page that handles the data is mounted on a 'custom'
QueryStringUrlCodingStrategy. In 'decode()' the strategy checks if
manipulations are needed. If not the strategy answers with a
ResourceStreamRequestTarget.
So here's the path that causes the error:
onClick-setResponsePage-decode-ResourceStreamRequestTarget
Once a link has been clicked no other links are clickable on the page.
The redirect seems to happen, but only once.
Say there are 3 files to download on the page, I would need to:
click link1 - download the file - refresh the page - click link2 -. etc.
I shouldn't need to refresh the page.
If I don't refresh the page, when I click link2 I'll get 'Channel busy -
postponing'.
AjaxLink Code:
public void onClick(AjaxRequestTarget target)
{
if(file.isOnline()) {
PageParameters params = new PageParameters();
params.add(id, String.valueOf(typeId));
params.add(type, type.toString());
setResponsePage(StageableFilePage.class, params);
}
else {
modal.show(target);
}
}
QueryStringUrlCodingStrategy Code:
public IRequestTarget decode(RequestParameters requestParameters) {
[..get id and fileType and make sure the user has priviledges..]
final StageableFile file = resolveFile(id, fileType);
if(file.isOnline()) {
IResourceStream resourceStream = new FileResourceStream(file);
//Content-type will be set by the ResourceStreamRequestTarget
ResourceStreamRequestTarget rsrt = new
ResourceStreamRequestTarget(resourceStream) {
@Override
public String getFileName() {
return file.getName();
}
};
return rsrt;
}
else {
return super.decode(requestParameters);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
