[ http://issues.apache.org/jira/browse/JELLY-85?page=comments#action_57879 ] Paul Libbrecht commented on JELLY-85: -------------------------------------
Mmmh, that means that any operation that intend to use the script-to-tag association have to be run within the same thread. Maybe this could be more explicit somewhere. Now... this means that JellySwing scripts should directly run in the AWT thread if they intend to run any jelly within the AWT thread (e.g. the body of Action), right? I've tried this and have managed to actually find back my tags and achieve a preliminary "reloadable" Swing components (so that a panel gets "re-populated" by jelly:swing as the result of an action). But I'd need to enrich the main Jelly class to add a -awt or -swing flag to start right away in the AWT thread. Anything against it ? paul > TagScript doesn't clear its cached tags after run() > --------------------------------------------------- > > Key: JELLY-85 > URL: http://issues.apache.org/jira/browse/JELLY-85 > Project: jelly > Type: Bug > Components: core / taglib.core > Versions: 1.0-beta-4 > Reporter: Scott Howlett > Attachments: StaticTagScript_patch.txt, TagScript_patch.txt, > includeAndDefineExample.zip > > TagScript caches the tags it generates in a ThreadLocal. At the beginning of > run() it checks to see if the context wants to cache tags - if not, it clears > the cache and regenerates it. > But there is no corresponding check and cache clearing at the end of run(). > So if a tag holds onto some significant resource, that resource will hang > around until the thread goes away or until the tag is run again. > I am using Jelly Swing extensively, and various tags end up attached to the > AWT Event thread for the lifetime of my application. > As a quick fix, I have a patch that simply repeats the check-and-clear-cache > behavior at the end of TagScript.run(). I also have a patch that adds this > behavior to StaticTagScript, whose run() never seems to clear cached tags. > I am probably just unclear, but it seems to me that there is a deeper issue > as well - the context is being asked whether it wants to cache tags, but the > result of this question affects the TagScript, which is really independent of > the context. It seems like if context wants to cache tags, perhaps the > ThreadLocal used for their storage ought to belong to the context somehow. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
