I agree that it's cleaner but here's why I didn't do it: It's important for the cache to exist because some tags need it just to run. So, I didn't want to keep the cache in with the context variables because that data is vulnerable to inherit/export setting on the context. If the cache is broken while the Script is running, some tags will break.
We decided that we didn't want to change the API of JellyContext... so I didn't know where to keep the cache. Maybe it's better to bite the bullet and implement a cache in the context. But, it might be a very temporary API change. -----Original Message----- From: Dion Gillard [mailto:[EMAIL PROTECTED] Sent: Thursday, December 16, 2004 8:30 PM To: Jakarta Commons Developers List Subject: Re: [jelly] Trying to understand ThreadLocal story This sounds a lot cleaner to me. On Thu, 16 Dec 2004 18:37:11 -0500, peter royal <[EMAIL PROTECTED]> wrote: > On Dec 16, 2004, at 10:43 AM, Paul Libbrecht wrote: > > Now... aren't we >just< missing a simple notion "run-session", passed > > between script-objects, where each TagScript could put it's tag ? > > A simple hash-table where the key is the tag-script seems to satisfy > > requirements. > > That run-session, in normal conditions, would be garbage collected at > > the end of the run(), at least. > > Basically, yes. Rather than caching tags in the TagScript, we > could/should cache them in a JellyContext. You could then discards the > JellyContext to force the Tag's to be GC'd > -pete > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- http://www.multitask.com.au/people/dion/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
