You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Christian Oldiges (JIRA)" <ji...@apache.org> on 2012/07/18 16:00:35 UTC
[jira] [Created] (WICKET-4661) Ajax channel busy flag not properly
cleared upon SUCCESSFUL callback executions
Christian Oldiges created WICKET-4661:
-----------------------------------------
Summary: Ajax channel busy flag not properly cleared upon SUCCESSFUL callback executions
Key: WICKET-4661
URL: https://issues.apache.org/jira/browse/WICKET-4661
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 6.0.0-beta3
Reporter: Christian Oldiges
The error is triggered if a custom AjaxChannel is defined using code like this in an AjaxEventbehavior:
@Override
protected void updateAjaxAttributes(AjaxRequestAttributes attributes) {
super.updateAjaxAttributes(attributes);
attributes.setChannel(new AjaxChannel("mychannel", Type.DROP));
}
Note: The channel type does NOT matter. Neither DROP nor QUEUE work.
My guess is, the fact the a named ajax channel is used results in the client side re-using the JavaScript Wicket.Channel instances.
In a re-used instance, the busy flag needs to be properly cleared after successfully executing an ajax call and its callback which is NOT done in the currently implemented code:
schedule: function (callback) {
if (this.busy === false) {
this.busy = true;
try {
return callback();
} catch (exception) {
this.busy = false;
Wicket.Log.error("An error occurred while executing Ajax request:" + exception);
}
} else {
Wicket.Log.info("Channel busy - postponing...");
A better, working solution would be:
schedule: function (callback) {
if (this.busy === false) {
this.busy = true;
try {
var callbackResult = callback();
this.busy = false;
return callbackResult;
} catch (exception) {
this.busy = false;
Wicket.Log.error("An error occurred while executing Ajax request:" + exception);
}
} else {
Wicket.Log.info("Channel busy - postponing...");
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4661) Ajax channel busy flag not properly
cleared upon SUCCESSFUL callback executions
Posted by "Christian Oldiges (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Oldiges updated WICKET-4661:
--------------------------------------
Description:
The error is triggered if a custom AjaxChannel is defined using code like this in an AjaxEventbehavior:
{code}
@Override
protected void updateAjaxAttributes(AjaxRequestAttributes attributes) {
super.updateAjaxAttributes(attributes);
attributes.setChannel(new AjaxChannel("mychannel", Type.DROP));
}
{code}
Note: The channel type does NOT matter. Neither DROP nor QUEUE work.
My guess is, the fact the a named ajax channel is used results in the client side re-using the JavaScript Wicket.Channel instances.
In a re-used instance, the busy flag needs to be properly cleared after successfully executing an ajax call and its callback which is NOT done in the currently implemented code:
{code}
schedule: function (callback) {
if (this.busy === false) {
this.busy = true;
try {
return callback();
} catch (exception) {
this.busy = false;
Wicket.Log.error("An error occurred while executing Ajax request:" + exception);
}
} else {
Wicket.Log.info("Channel busy - postponing...");
{code}
A better, working solution would be:
{code}
schedule: function (callback) {
if (this.busy === false) {
this.busy = true;
try {
var callbackResult = callback();
this.busy = false;
return callbackResult;
} catch (exception) {
this.busy = false;
Wicket.Log.error("An error occurred while executing Ajax request:" + exception);
}
} else {
Wicket.Log.info("Channel busy - postponing...");
{code}
was:
The error is triggered if a custom AjaxChannel is defined using code like this in an AjaxEventbehavior:
@Override
protected void updateAjaxAttributes(AjaxRequestAttributes attributes) {
super.updateAjaxAttributes(attributes);
attributes.setChannel(new AjaxChannel("mychannel", Type.DROP));
}
Note: The channel type does NOT matter. Neither DROP nor QUEUE work.
My guess is, the fact the a named ajax channel is used results in the client side re-using the JavaScript Wicket.Channel instances.
In a re-used instance, the busy flag needs to be properly cleared after successfully executing an ajax call and its callback which is NOT done in the currently implemented code:
schedule: function (callback) {
if (this.busy === false) {
this.busy = true;
try {
return callback();
} catch (exception) {
this.busy = false;
Wicket.Log.error("An error occurred while executing Ajax request:" + exception);
}
} else {
Wicket.Log.info("Channel busy - postponing...");
A better, working solution would be:
schedule: function (callback) {
if (this.busy === false) {
this.busy = true;
try {
var callbackResult = callback();
this.busy = false;
return callbackResult;
} catch (exception) {
this.busy = false;
Wicket.Log.error("An error occurred while executing Ajax request:" + exception);
}
} else {
Wicket.Log.info("Channel busy - postponing...");
> Ajax channel busy flag not properly cleared upon SUCCESSFUL callback executions
> -------------------------------------------------------------------------------
>
> Key: WICKET-4661
> URL: https://issues.apache.org/jira/browse/WICKET-4661
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.0.0-beta3
> Reporter: Christian Oldiges
>
> The error is triggered if a custom AjaxChannel is defined using code like this in an AjaxEventbehavior:
> {code}
> @Override
> protected void updateAjaxAttributes(AjaxRequestAttributes attributes) {
> super.updateAjaxAttributes(attributes);
> attributes.setChannel(new AjaxChannel("mychannel", Type.DROP));
> }
> {code}
> Note: The channel type does NOT matter. Neither DROP nor QUEUE work.
> My guess is, the fact the a named ajax channel is used results in the client side re-using the JavaScript Wicket.Channel instances.
> In a re-used instance, the busy flag needs to be properly cleared after successfully executing an ajax call and its callback which is NOT done in the currently implemented code:
> {code}
> schedule: function (callback) {
> if (this.busy === false) {
> this.busy = true;
> try {
> return callback();
> } catch (exception) {
> this.busy = false;
> Wicket.Log.error("An error occurred while executing Ajax request:" + exception);
> }
> } else {
> Wicket.Log.info("Channel busy - postponing...");
> {code}
> A better, working solution would be:
> {code}
> schedule: function (callback) {
> if (this.busy === false) {
> this.busy = true;
> try {
> var callbackResult = callback();
> this.busy = false;
> return callbackResult;
> } catch (exception) {
> this.busy = false;
> Wicket.Log.error("An error occurred while executing Ajax request:" + exception);
> }
> } else {
> Wicket.Log.info("Channel busy - postponing...");
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4661) Ajax channel busy flag not properly
cleared upon SUCCESSFUL callback executions
Posted by "Jan Riehn (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jan Riehn updated WICKET-4661:
------------------------------
Attachment: wicket-4661.patch
possible solution as patch
> Ajax channel busy flag not properly cleared upon SUCCESSFUL callback executions
> -------------------------------------------------------------------------------
>
> Key: WICKET-4661
> URL: https://issues.apache.org/jira/browse/WICKET-4661
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.0.0-beta3
> Reporter: Christian Oldiges
> Attachments: wicket-4661.patch
>
>
> The error is triggered if a custom AjaxChannel is defined using code like this in an AjaxEventbehavior:
> {noformat}
> @Override
> protected void updateAjaxAttributes(AjaxRequestAttributes attributes) {
> super.updateAjaxAttributes(attributes);
> attributes.setChannel(new AjaxChannel("mychannel", Type.DROP));
> }
> {noformat}
> Note: The channel type does NOT matter. Neither DROP nor QUEUE work.
> My guess is, the fact the a named ajax channel is used results in the client side re-using the JavaScript Wicket.Channel instances.
> In a re-used instance, the busy flag needs to be properly cleared after successfully executing an ajax call and its callback which is NOT done in the currently implemented code:
> {noformat}
> schedule: function (callback) {
> if (this.busy === false) {
> this.busy = true;
> try {
> return callback();
> } catch (exception) {
> this.busy = false;
> Wicket.Log.error("An error occurred while executing Ajax request:" + exception);
> }
> } else {
> Wicket.Log.info("Channel busy - postponing...");
> {noformat}
> A better, working solution would be:
> {noformat}
> schedule: function (callback) {
> if (this.busy === false) {
> this.busy = true;
> try {
> var callbackResult = callback();
> this.busy = false;
> return callbackResult;
> } catch (exception) {
> this.busy = false;
> Wicket.Log.error("An error occurred while executing Ajax request:" + exception);
> }
> } else {
> Wicket.Log.info("Channel busy - postponing...");
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (WICKET-4661) Ajax channel busy flag not properly
cleared upon SUCCESSFUL callback executions
Posted by "Sven Meier (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sven Meier resolved WICKET-4661.
--------------------------------
Resolution: Fixed
Fix Version/s: 6.0.0
Assignee: Sven Meier
Problem was that ChannelManager#done() always got an undefined channel, thus informing the wrong channel (the default '0') of completion.
> Ajax channel busy flag not properly cleared upon SUCCESSFUL callback executions
> -------------------------------------------------------------------------------
>
> Key: WICKET-4661
> URL: https://issues.apache.org/jira/browse/WICKET-4661
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.0.0-beta3
> Reporter: Christian Oldiges
> Assignee: Sven Meier
> Fix For: 6.0.0
>
> Attachments: wicket-4661.patch
>
>
> The error is triggered if a custom AjaxChannel is defined using code like this in an AjaxEventbehavior:
> {noformat}
> @Override
> protected void updateAjaxAttributes(AjaxRequestAttributes attributes) {
> super.updateAjaxAttributes(attributes);
> attributes.setChannel(new AjaxChannel("mychannel", Type.DROP));
> }
> {noformat}
> Note: The channel type does NOT matter. Neither DROP nor QUEUE work.
> My guess is, the fact the a named ajax channel is used results in the client side re-using the JavaScript Wicket.Channel instances.
> In a re-used instance, the busy flag needs to be properly cleared after successfully executing an ajax call and its callback which is NOT done in the currently implemented code:
> {noformat}
> schedule: function (callback) {
> if (this.busy === false) {
> this.busy = true;
> try {
> return callback();
> } catch (exception) {
> this.busy = false;
> Wicket.Log.error("An error occurred while executing Ajax request:" + exception);
> }
> } else {
> Wicket.Log.info("Channel busy - postponing...");
> {noformat}
> A better, working solution would be:
> {noformat}
> schedule: function (callback) {
> if (this.busy === false) {
> this.busy = true;
> try {
> var callbackResult = callback();
> this.busy = false;
> return callbackResult;
> } catch (exception) {
> this.busy = false;
> Wicket.Log.error("An error occurred while executing Ajax request:" + exception);
> }
> } else {
> Wicket.Log.info("Channel busy - postponing...");
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4661) Ajax channel busy flag not properly
cleared upon SUCCESSFUL callback executions
Posted by "Christian Oldiges (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Oldiges updated WICKET-4661:
--------------------------------------
Description:
The error is triggered if a custom AjaxChannel is defined using code like this in an AjaxEventbehavior:
{code}
@Override
protected void updateAjaxAttributes(AjaxRequestAttributes attributes) {
super.updateAjaxAttributes(attributes);
attributes.setChannel(new AjaxChannel("mychannel", Type.DROP));
}
{code}
Note: The channel type does NOT matter. Neither DROP nor QUEUE work.
My guess is, the fact the a named ajax channel is used results in the client side re-using the JavaScript Wicket.Channel instances.
In a re-used instance, the busy flag needs to be properly cleared after successfully executing an ajax call and its callback which is NOT done in the currently implemented code:
{code}
schedule: function (callback) {
if (this.busy === false) {
this.busy = true;
try {
return callback();
} catch (exception) {
this.busy = false;
Wicket.Log.error("An error occurred while executing Ajax request:" + exception);
}
} else {
Wicket.Log.info("Channel busy - postponing...");
{code}
A better, working solution would be:
{code}
schedule: function (callback) {
if (this.busy === false) {
this.busy = true;
try {
var callbackResult = callback();
this.busy = false;
return callbackResult;
} catch (exception) {
this.busy = false;
Wicket.Log.error("An error occurred while executing Ajax request:" + exception);
}
} else {
Wicket.Log.info("Channel busy - postponing...");
{code}
was:
The error is triggered if a custom AjaxChannel is defined using code like this in an AjaxEventbehavior:
{code}
@Override
protected void updateAjaxAttributes(AjaxRequestAttributes attributes) {
super.updateAjaxAttributes(attributes);
attributes.setChannel(new AjaxChannel("mychannel", Type.DROP));
}
{code}
Note: The channel type does NOT matter. Neither DROP nor QUEUE work.
My guess is, the fact the a named ajax channel is used results in the client side re-using the JavaScript Wicket.Channel instances.
In a re-used instance, the busy flag needs to be properly cleared after successfully executing an ajax call and its callback which is NOT done in the currently implemented code:
{code}
schedule: function (callback) {
if (this.busy === false) {
this.busy = true;
try {
return callback();
} catch (exception) {
this.busy = false;
Wicket.Log.error("An error occurred while executing Ajax request:" + exception);
}
} else {
Wicket.Log.info("Channel busy - postponing...");
{code}
A better, working solution would be:
{code}
schedule: function (callback) {
if (this.busy === false) {
this.busy = true;
try {
var callbackResult = callback();
this.busy = false;
return callbackResult;
} catch (exception) {
this.busy = false;
Wicket.Log.error("An error occurred while executing Ajax request:" + exception);
}
} else {
Wicket.Log.info("Channel busy - postponing...");
{code}
> Ajax channel busy flag not properly cleared upon SUCCESSFUL callback executions
> -------------------------------------------------------------------------------
>
> Key: WICKET-4661
> URL: https://issues.apache.org/jira/browse/WICKET-4661
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.0.0-beta3
> Reporter: Christian Oldiges
>
> The error is triggered if a custom AjaxChannel is defined using code like this in an AjaxEventbehavior:
> {code}
> @Override
> protected void updateAjaxAttributes(AjaxRequestAttributes attributes) {
> super.updateAjaxAttributes(attributes);
> attributes.setChannel(new AjaxChannel("mychannel", Type.DROP));
> }
> {code}
> Note: The channel type does NOT matter. Neither DROP nor QUEUE work.
> My guess is, the fact the a named ajax channel is used results in the client side re-using the JavaScript Wicket.Channel instances.
> In a re-used instance, the busy flag needs to be properly cleared after successfully executing an ajax call and its callback which is NOT done in the currently implemented code:
> {code}
> schedule: function (callback) {
> if (this.busy === false) {
> this.busy = true;
> try {
> return callback();
> } catch (exception) {
> this.busy = false;
> Wicket.Log.error("An error occurred while executing Ajax request:" + exception);
> }
> } else {
> Wicket.Log.info("Channel busy - postponing...");
> {code}
> A better, working solution would be:
> {code}
> schedule: function (callback) {
> if (this.busy === false) {
> this.busy = true;
> try {
> var callbackResult = callback();
> this.busy = false;
> return callbackResult;
> } catch (exception) {
> this.busy = false;
> Wicket.Log.error("An error occurred while executing Ajax request:" + exception);
> }
> } else {
> Wicket.Log.info("Channel busy - postponing...");
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4661) Ajax channel busy flag not properly
cleared upon SUCCESSFUL callback executions
Posted by "Christian Oldiges (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Oldiges updated WICKET-4661:
--------------------------------------
Description:
The error is triggered if a custom AjaxChannel is defined using code like this in an AjaxEventbehavior:
{noformat}
@Override
protected void updateAjaxAttributes(AjaxRequestAttributes attributes) {
super.updateAjaxAttributes(attributes);
attributes.setChannel(new AjaxChannel("mychannel", Type.DROP));
}
{noformat}
Note: The channel type does NOT matter. Neither DROP nor QUEUE work.
My guess is, the fact the a named ajax channel is used results in the client side re-using the JavaScript Wicket.Channel instances.
In a re-used instance, the busy flag needs to be properly cleared after successfully executing an ajax call and its callback which is NOT done in the currently implemented code:
{noformat}
schedule: function (callback) {
if (this.busy === false) {
this.busy = true;
try {
return callback();
} catch (exception) {
this.busy = false;
Wicket.Log.error("An error occurred while executing Ajax request:" + exception);
}
} else {
Wicket.Log.info("Channel busy - postponing...");
{noformat}
A better, working solution would be:
{noformat}
schedule: function (callback) {
if (this.busy === false) {
this.busy = true;
try {
var callbackResult = callback();
this.busy = false;
return callbackResult;
} catch (exception) {
this.busy = false;
Wicket.Log.error("An error occurred while executing Ajax request:" + exception);
}
} else {
Wicket.Log.info("Channel busy - postponing...");
{noformat}
was:
The error is triggered if a custom AjaxChannel is defined using code like this in an AjaxEventbehavior:
{code}
@Override
protected void updateAjaxAttributes(AjaxRequestAttributes attributes) {
super.updateAjaxAttributes(attributes);
attributes.setChannel(new AjaxChannel("mychannel", Type.DROP));
}
{code}
Note: The channel type does NOT matter. Neither DROP nor QUEUE work.
My guess is, the fact the a named ajax channel is used results in the client side re-using the JavaScript Wicket.Channel instances.
In a re-used instance, the busy flag needs to be properly cleared after successfully executing an ajax call and its callback which is NOT done in the currently implemented code:
{code}
schedule: function (callback) {
if (this.busy === false) {
this.busy = true;
try {
return callback();
} catch (exception) {
this.busy = false;
Wicket.Log.error("An error occurred while executing Ajax request:" + exception);
}
} else {
Wicket.Log.info("Channel busy - postponing...");
{code}
A better, working solution would be:
{code}
schedule: function (callback) {
if (this.busy === false) {
this.busy = true;
try {
var callbackResult = callback();
this.busy = false;
return callbackResult;
} catch (exception) {
this.busy = false;
Wicket.Log.error("An error occurred while executing Ajax request:" + exception);
}
} else {
Wicket.Log.info("Channel busy - postponing...");
{code}
> Ajax channel busy flag not properly cleared upon SUCCESSFUL callback executions
> -------------------------------------------------------------------------------
>
> Key: WICKET-4661
> URL: https://issues.apache.org/jira/browse/WICKET-4661
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.0.0-beta3
> Reporter: Christian Oldiges
>
> The error is triggered if a custom AjaxChannel is defined using code like this in an AjaxEventbehavior:
> {noformat}
> @Override
> protected void updateAjaxAttributes(AjaxRequestAttributes attributes) {
> super.updateAjaxAttributes(attributes);
> attributes.setChannel(new AjaxChannel("mychannel", Type.DROP));
> }
> {noformat}
> Note: The channel type does NOT matter. Neither DROP nor QUEUE work.
> My guess is, the fact the a named ajax channel is used results in the client side re-using the JavaScript Wicket.Channel instances.
> In a re-used instance, the busy flag needs to be properly cleared after successfully executing an ajax call and its callback which is NOT done in the currently implemented code:
> {noformat}
> schedule: function (callback) {
> if (this.busy === false) {
> this.busy = true;
> try {
> return callback();
> } catch (exception) {
> this.busy = false;
> Wicket.Log.error("An error occurred while executing Ajax request:" + exception);
> }
> } else {
> Wicket.Log.info("Channel busy - postponing...");
> {noformat}
> A better, working solution would be:
> {noformat}
> schedule: function (callback) {
> if (this.busy === false) {
> this.busy = true;
> try {
> var callbackResult = callback();
> this.busy = false;
> return callbackResult;
> } catch (exception) {
> this.busy = false;
> Wicket.Log.error("An error occurred while executing Ajax request:" + exception);
> }
> } else {
> Wicket.Log.info("Channel busy - postponing...");
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira