[ http://nagoya.apache.org/jira/browse/JELLY-85?page=comments#action_56996 ] Paul Libbrecht commented on JELLY-85: -------------------------------------
I think this is the right issue to post three possible approaches towards the tag-caching problem which was solved incompletely by the weak-reference wrapper (see JELLY-166). This problem is even known hard to James, the father of Jelly, as he stated once in an interview. Just to summarize the requirement: jelly scripts are structured using Script objects. Script functionality is provided by Tags and there is a need to reference tags from scripts and this maybe several times. As we want jelly-scripts to be able to run in simultaneous threads, an approach using ThreadLocal instance-members was made originally. It was impossible to clean-up. This was changed to the usage of a WeakReference... this got cleaned-up too quickly. The three approaches that I see are as follows: 1 keep the instance ThreadLocal but maintain, as static ThreadLocal, a list of all these thread-locals and clear them when we're finished. This requires the least changes as it only adds a public static method to clean-up-tags-for-this-thread. It may be incomplete though. 2 use a static ThreadLocal which is a map that associates scripts to tags, and clear when finished. This adds just two or three methods but has the advantage of making this map explicit which can be useful in case the same tags want to be run again (e.g. Jelly-Swing's action tags) 3 use an explicit tag-holder mechanism in jelly-context... entirely disjoint from the thread. This is the cleanest but it requires all invocations to getTag() configureTag() to be added with the jelly-context as parameter. I think this may break a lot of things! I think that, if we want to reach the release soon, we'd probably be better for 2. In cases 1 and 2, clean-up has to be made explicit (in case 3, gc-ing the context should be enough). So the lack of change in the API-signatures results in a change in the API documentation: users-scripts will need to add another call to clean-up. Thanks to bring your opinions ! paul > TagScript doesn't clear its cached tags after run() > --------------------------------------------------- > > Key: JELLY-85 > URL: http://nagoya.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://nagoya.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]
