No, this is how it's always worked. It has to work this way in order to support some of the more esoteric features of Jelly. I also tried to change this when fixing the memory leak. As you discovered, it's currently stuck this way. Wit can be fixed but, as I recall, it would mean changing the functionality of some tag libraries and possibly dynamic tags.
-----Original Message----- From: Paul Libbrecht [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 16, 2005 5:04 AM To: Jakarta Commons Developers List Subject: Re: [jelly] 1.0-final problem wrt tag caching Just for me to be sure to understand... this is definitely a change compared to pre-1.0, or ? Can you maybe update the javadoc of setCacheTags/getCacheTags or should we work on a page "lifecycle of a tag" ? paul Le 16 août 05, à 03:56, peter royal a écrit : > On Aug 15, 2005, at 3:22 AM, Paul Libbrecht wrote: >> At least a quick summary of caching would be that: if caching is >> disabled, the tag object is renewed at the beginning of every new >> run. >> (where I understood disabled caching would imply the tag would >> disappear much earlier). >> >> Maybe that's a simple formulation... > > That's exactly correct. On a per-thread basis, TagScript.run() results > in a new Tag instance if caching is not enabled. --------------------------------------------------------------------- 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]
