commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans Gilde <>
Subject RE: [jelly] 1.0-final problem wrt tag caching
Date Wed, 17 Aug 2005 03:48:36 GMT
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 [] 
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" ?


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, results 
> in a new Tag instance if caching is not enabled.

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message