[jira] Commented: (JELLY-85) TagScript doesn't clear its cached tags after run()
[ http://issues.apache.org/jira/browse/JELLY-85?page=comments#action_58217 ] dion gillard commented on JELLY-85: --- This bug report is now redundant and should be closed, right Hans and 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]
Re: [jira] Commented: (JELLY-85) TagScript doesn't clear its cached tags after run()
For 1.1, or ? There are a few other issues around that talk about this... paul Le 21 janv. 05, à 16:23, Hans Gilde (JIRA) a écrit : Well... It's not how Jelly works now, so I'll have to think about it. I'm really in favor of this: splitting off the different bits of functionality from JellyContext. While we're doing this, we could think about which parts are thread safe and which parts need to be kept in the same thread. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JELLY-85) TagScript doesn't clear its cached tags after run()
[ http://issues.apache.org/jira/browse/JELLY-85?page=comments#action_57890 ] Hans Gilde commented on JELLY-85: - Well... It's not how Jelly works now, so I'll have to think about it. I'm really in favor of this: splitting off the different bits of functionality from JellyContext. While we're doing this, we could think about which parts are thread safe and which parts need to be kept in the same thread. > 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]
[jira] Commented: (JELLY-85) TagScript doesn't clear its cached tags after run()
[ 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]
[jira] Commented: (JELLY-85) TagScript doesn't clear its cached tags after run()
[ http://issues.apache.org/jira/browse/JELLY-85?page=comments#action_57868 ] Hans Gilde commented on JELLY-85: - Absolutely, this would be much easier. But it gets complicated when you look at what creating a new context means. Like, contexts search up the ie parent tree for variables and other stuff. And tags can search up from a thread tag to fiind parent... > 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]
[jira] Commented: (JELLY-85) TagScript doesn't clear its cached tags after run()
[ http://issues.apache.org/jira/browse/JELLY-85?page=comments#action_57828 ] Paul Libbrecht commented on JELLY-85: - Is "thread guarantees" the following excerpt of Tag interface javadoc? > A Tag is only ever used by a single thread so that Tag developers > do not need to concern themselves with mutli-threading > issues when writing a Tag. Wouldn't i be simpler to say that Thread safety is guaranteed by the usage of a single context per thread ? Or do you have situations where a single context is used by several threads ? My tests and personal usages are fine with the current status of the tags, even with your memory-leak-test. 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]
[jira] Commented: (JELLY-85) TagScript doesn't clear its cached tags after run()
[ http://issues.apache.org/jira/browse/JELLY-85?page=comments#action_57804 ] dion gillard commented on JELLY-85: --- Hans, looks ok to me. Will run some tests tonight > 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]
[jira] Commented: (JELLY-85) TagScript doesn't clear its cached tags after run()
[ http://issues.apache.org/jira/browse/JELLY-85?page=comments#action_57802 ] Hans Gilde commented on JELLY-85: - Paul, I made some changes to your code based on my experience using Jelly. And I fixed the part about thread guarantees for Tag instances. But, it's basically unchanged, I hope you approve. > 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]
[jira] Commented: (JELLY-85) TagScript doesn't clear its cached tags after run()
[ http://issues.apache.org/jira/browse/JELLY-85?page=comments#action_57616 ] Paul Libbrecht commented on JELLY-85: - I have now committed modifications to TagScript and JellyContext to prevent any caching outside of the JellyContext. At least disposing of the JellyContext, the script objects, or calling the context.clear() will clear all references to tags. Jelly now builds fine. It would be nice if users that experienced this give a stab at the latest snapshot, preferably from cvs. thanks 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]
[jira] Commented: (JELLY-85) TagScript doesn't clear its cached tags after run()
[ 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]
[jira] Commented: (JELLY-85) TagScript doesn't clear its cached tags after run()
[ http://nagoya.apache.org/jira/browse/JELLY-85?page=comments#action_56756 ] dion gillard commented on JELLY-85: --- Hans and Paul, 'The attached pair of scripts seems to constantly raise the exception "Attempt to use a script that has been garbage collected.".' Can we put the attachment and work against JELLY-166, that's where the error above is first reported. I don't think it has much to do with JELLY-85 > 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]
[jira] Commented: (JELLY-85) TagScript doesn't clear its cached tags after run()
[ http://nagoya.apache.org/jira/browse/JELLY-85?page=comments#action_56751 ] Hans Gilde commented on JELLY-85: - this is a problem with code introduced in the patch for JELLY-148 > 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]
[jira] Commented: (JELLY-85) TagScript doesn't clear its cached tags after run()
The following comment has been added to this issue: Author: Guido Anzuoni Created: Fri, 17 Sep 2004 6:26 AM Body: With a TagScript instance created by XMLParser in its startElement and with every instance of TagScript declaring a ThreadLocal, jelly is unusable in tipical servlet environment. Caching should be at higher level. Jelly core should allow the run of scripts without leaving any trace of itself at the end. - View this comment: http://issues.apache.org/jira/browse/JELLY-85?page=comments#action_53167 - View the issue: http://issues.apache.org/jira/browse/JELLY-85 Here is an overview of the issue: - Key: JELLY-85 Summary: TagScript doesn't clear its cached tags after run() Type: Bug Status: Unassigned Priority: Major Project: jelly Components: core / taglib.core Versions: 1.0-beta-4 Assignee: Reporter: Scott Howlett Created: Tue, 16 Sep 2003 8:16 PM Updated: Fri, 17 Sep 2004 6:26 AM Description: 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. - JIRA INFORMATION: 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]
[jira] Commented: (JELLY-85) TagScript doesn't clear its cached tags after run()
The following comment has been added to this issue: Author: Hans Gilde Created: Sun, 12 Sep 2004 4:11 PM Body: Having looked at this some more, this TagScript should not clear its cache after run(). The cache reuses a Tag implementation between several runs of the same script, in the same thread. It does not reuse the same Tag implementation multiple times within the same script. The cache is a ThreadLocal object that is a member variable of TagScript. A seperate TagScript object is always created for every instance of a tag encountered in an XML document. So, there is no choice but to have a Tag implementation for every XML element in the document. What the cache does do is ensure that the second time you run the script in the same thread, it will not create a second set of Tag implementations. - View this comment: http://issues.apache.org/jira/browse/JELLY-85?page=comments#action_53051 - View the issue: http://issues.apache.org/jira/browse/JELLY-85 Here is an overview of the issue: - Key: JELLY-85 Summary: TagScript doesn't clear its cached tags after run() Type: Bug Status: Unassigned Priority: Major Project: jelly Components: core / taglib.core Versions: 1.0-beta-4 Assignee: Reporter: Scott Howlett Created: Tue, 16 Sep 2003 8:16 PM Updated: Sun, 12 Sep 2004 4:11 PM Description: 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. - JIRA INFORMATION: 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]
[jira] Commented: (JELLY-85) TagScript doesn't clear its cached tags after run()
The following comment has been added to this issue: Author: Hans Gilde Created: Mon, 30 Aug 2004 9:08 PM Body: See JELLY-122 for a partial fix. - View this comment: http://issues.apache.org/jira/browse/JELLY-85?page=comments#action_37937 - View the issue: http://issues.apache.org/jira/browse/JELLY-85 Here is an overview of the issue: - Key: JELLY-85 Summary: TagScript doesn't clear its cached tags after run() Type: Bug Status: Unassigned Priority: Major Project: jelly Components: core / taglib.core Versions: 1.0-beta-4 Assignee: Reporter: Scott Howlett Created: Tue, 16 Sep 2003 8:16 PM Updated: Mon, 30 Aug 2004 9:08 PM Description: 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. - JIRA INFORMATION: 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]
[jira] Commented: (JELLY-85) TagScript doesn't clear its cached tags after run()
The following comment has been added to this issue: Author: Hans Gilde Created: Sat, 28 Aug 2004 6:58 PM Body: I suggest that the problem is not the fact that the TagScript caches the Tag implementation, but the fact that the Tag implementation caches the heavy object after execution. This is fortunate, because it's a whole lot easier for a Tag to stop caching it's state than it is for a TagScript to stop caching it's Tag implementation. It has to do with the way that caching works, which could be changed but not without big impact. - View this comment: http://issues.apache.org/jira/browse/JELLY-85?page=comments#action_37889 - View the issue: http://issues.apache.org/jira/browse/JELLY-85 Here is an overview of the issue: - Key: JELLY-85 Summary: TagScript doesn't clear its cached tags after run() Type: Bug Status: Unassigned Priority: Major Project: jelly Components: core / taglib.core Versions: 1.0-beta-4 Assignee: Reporter: Scott Howlett Created: Tue, 16 Sep 2003 8:16 PM Updated: Sat, 28 Aug 2004 6:58 PM Description: 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. - JIRA INFORMATION: 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]
[jira] Commented: (JELLY-85) TagScript doesn't clear its cached tags after run()
The following comment has been added to this issue: Author: dion gillard Created: Wed, 11 Aug 2004 8:51 PM Body: This patch has broken the define taglib and it's test cases. I'm backing it out until a replacement patch can be made that doesn't do this. - View this comment: http://issues.apache.org/jira/browse/JELLY-85?page=comments#action_37198 - View the issue: http://issues.apache.org/jira/browse/JELLY-85 Here is an overview of the issue: - Key: JELLY-85 Summary: TagScript doesn't clear its cached tags after run() Type: Bug Status: Unassigned Priority: Major Project: jelly Components: core / taglib.core Versions: 1.0-beta-4 Assignee: Reporter: Scott Howlett Created: Tue, 16 Sep 2003 8:16 PM Updated: Wed, 11 Aug 2004 8:51 PM Description: 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. - JIRA INFORMATION: 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]
