Issue Details (XML | Word | Printable)

Key: JELLY-85
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Unassigned
Reporter: Scott Howlett
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Commons Jelly

TagScript doesn't clear its cached tags after run()

Created: 17/Sep/03 03:16 AM   Updated: 28/Jan/05 09:46 PM
Return to search
Component/s: core / taglib.core
Affects Version/s: 1.0-beta-4
Fix Version/s: 1.0-RC2

Time Tracking:
Not Specified

File Attachments:
  Size
Zip Archive Licensed for inclusion in ASF works includeAndDefineExample.zip 2004-12-15 01:53 PM Paul Libbrecht 0.6 kB
Text File StaticTagScript_patch.txt 2003-09-17 03:17 AM Scott Howlett 0.8 kB
Text File TagScript_patch.txt 2003-09-17 03:17 AM Scott Howlett 0.5 kB

Resolution Date: 28/Jan/05 09:46 PM


 Description  « Hide
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.



 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
No work has yet been logged on this issue.