You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tapestry.apache.org by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org> on 2011/02/11 11:16:57 UTC
[jira] Updated: (TAP5-1208) In development mode, Tapestry should
"shadow" field & parameter values to instance variables, to assist with
debugging
[ https://issues.apache.org/jira/browse/TAP5-1208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship updated TAP5-1208:
---------------------------------------
Description:
Since Tapestry 5.2 and the end of page pooling, all mutable field state (unclaimed fields, parameter fields, persisted fields, etc.) have their values stored in an external, per-thread HashMap, which allows page instances (along with components within pages) to be shared across threads.
However, when debugging, all those fields are still present but have null (or default) values.
When in development mode, it would be great if reading or writing to the fields would "shadow" the value into the field, as well as do the other updates (moving the content to or from the HashMap, etc.).
This would be pointless in production mode (the instance fields would be constantly overwritten by multiple threads) and possibly introduce memory leaks (as temporary objects would be referenced from the fields). However, quite reasonable to do this for development mode.
Improvement related to May 2010 thread: [T5] debugging in eclipse
http://mail-archives.apache.org/mod_mbox/tapestry-users/201005.mbox/%3CAANLkTinOfXeSmALOYxzR-OSd4uZwTDC_Qt1j4igZgVFP@mail.gmail.com%3E
As noted in the thread, values can only be seen when debugging by inspecting the related conduit due to the class transformation that takes place behind the scenes.
Actually, in my experience, this used to be the case but now with the most recent snapshots I can't even do that.
Later on in the thread a suggestion is made to modify UncaimedFieldWorker.
http://mail-archives.apache.org/mod_mbox/tapestry-users/201005.mbox/%3CAANLkTimTAtLKsZbYntUm2pwN70KiwnnwlwJr4gmWL9V3@mail.gmail.com%3E
I don't know if this is correct or not but I would think that this would be a useful improvement over the way things currently work.
was:
Improvement related to May 2010 thread: [T5] debugging in eclipse
http://mail-archives.apache.org/mod_mbox/tapestry-users/201005.mbox/%3CAANLkTinOfXeSmALOYxzR-OSd4uZwTDC_Qt1j4igZgVFP@mail.gmail.com%3E
As noted in the thread, values can only be seen when debugging by inspecting the related conduit due to the class transformation that takes place behind the scenes.
Actually, in my experience, this used to be the case but now with the most recent snapshots I can't even do that.
Later on in the thread a suggestion is made to modify UncaimedFieldWorker.
http://mail-archives.apache.org/mod_mbox/tapestry-users/201005.mbox/%3CAANLkTimTAtLKsZbYntUm2pwN70KiwnnwlwJr4gmWL9V3@mail.gmail.com%3E
I don't know if this is correct or not but I would think that this would be a useful improvement over the way things currently work.
Summary: In development mode, Tapestry should "shadow" field & parameter values to instance variables, to assist with debugging (was: Debugging in Tapestry 5.2)
> In development mode, Tapestry should "shadow" field & parameter values to instance variables, to assist with debugging
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: TAP5-1208
> URL: https://issues.apache.org/jira/browse/TAP5-1208
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.3, 5.2
> Reporter: Mike M Pestorich
> Assignee: Howard M. Lewis Ship
>
> Since Tapestry 5.2 and the end of page pooling, all mutable field state (unclaimed fields, parameter fields, persisted fields, etc.) have their values stored in an external, per-thread HashMap, which allows page instances (along with components within pages) to be shared across threads.
> However, when debugging, all those fields are still present but have null (or default) values.
> When in development mode, it would be great if reading or writing to the fields would "shadow" the value into the field, as well as do the other updates (moving the content to or from the HashMap, etc.).
> This would be pointless in production mode (the instance fields would be constantly overwritten by multiple threads) and possibly introduce memory leaks (as temporary objects would be referenced from the fields). However, quite reasonable to do this for development mode.
> Improvement related to May 2010 thread: [T5] debugging in eclipse
> http://mail-archives.apache.org/mod_mbox/tapestry-users/201005.mbox/%3CAANLkTinOfXeSmALOYxzR-OSd4uZwTDC_Qt1j4igZgVFP@mail.gmail.com%3E
> As noted in the thread, values can only be seen when debugging by inspecting the related conduit due to the class transformation that takes place behind the scenes.
> Actually, in my experience, this used to be the case but now with the most recent snapshots I can't even do that.
> Later on in the thread a suggestion is made to modify UncaimedFieldWorker.
> http://mail-archives.apache.org/mod_mbox/tapestry-users/201005.mbox/%3CAANLkTimTAtLKsZbYntUm2pwN70KiwnnwlwJr4gmWL9V3@mail.gmail.com%3E
> I don't know if this is correct or not but I would think that this would be a useful improvement over the way things currently work.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira