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 behavior. -----Original Message----- From: Hans Gilde [mailto:[EMAIL PROTECTED] 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 [mailto:[EMAIL PROTECTED] 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! paul --------------------------------------------------------------------- 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]
