commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans Gilde <>
Subject RE: [jelly] SOLVED: Maven issue with Hans memory leak patch
Date Sat, 21 May 2005 06:17:40 GMT
Wait... strike this new patch. My old one should be fine. Now I'm jumping to
conclusions because I haven't looked at it for so long.

Brett, what's being reused where it wasn't before? I would not expect this

-----Original Message-----
From: Hans Gilde [] 
Sent: Saturday, May 21, 2005 1:48 AM
To: 'Jakarta Commons Developers List'
Subject: RE: [jelly] SOLVED: Maven issue with Hans memory leak patch

Sorry not to be around so much any more. I got laid off and had to find a
new job.

I'm so sorry to say that my memory leak patch has a big flaw in it. It
should not have caused the tag to be improperly reused.

I'm happy to say that I have a fix (replacement), which is attached. This
patch should work without the fix to Maven.

I didn't like the tag cache for two reasons: (1) it practically guarantees
leaks for applications that use the current jelly and aren't expecting it
and (2) I thought I had a good solution, which has now taken much longer to
implement than I expected.

Paul, you probably know, but you can't disable caching in the current code,
because some kinds of tags rely on it. This is a big issue with Jelly.
However, in the next version (should we actually get there :), I agree that
the whole life cycle should be separated.

-----Original Message-----
From: Paul Libbrecht [] 
Sent: Sunday, May 01, 2005 2:32 PM
To: Jakarta Commons Developers List
Subject: Re: [jelly] SOLVED: Maven issue with Hans memory leak patch

Le 1 mai 05, à 19:36, peter royal a écrit :
> On May 1, 2005, at 9:09 AM, Brett Porter wrote:
>> I've solved this problem. One of the jelly tags was relying on a new
>> instance being created, but the instance is now being reused. Note 
>> that
>> the tag is the same call from the same script, so I assume that this 
>> is
>> valid, so I have made the tag not be stateful and it fixed the Maven
>> problem.
>> Does anyone know if this is correct behaviour?
> Sounds correct to me :)

Yes, this sounds also correct to me...
I think the assumption that a new instance of tag-objects be created 
was correct if one would set not to "cache" tags (using the formerly 
available setCacheTags method); this was probably the default.
SInce the thread-local fixes, all tags are cached and...

I am wondering wether there would be wish to bring back the method 
setCacheTags and actually disable caching in some circumstances. I 
would rather say it's better to keep it out as it makes life-cycle 
easier to write for tags (and one can still clear the contexts).

Brett, I'm really looking forward to your commit (which will include 
Hans' patch, then, correct?).
 From there on we should hunt for 1.0!


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

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

View raw message