DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=33934>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33934 ------- Additional Comments From [EMAIL PROTECTED] 2007-01-12 11:11 ------- NOTE: I'm new to asf bugzilla, so please forgive any mis-use of this website and please let me know if there is a better way for me to submit a request like this in the future! :\ I am having the same problem (memory "leak") with this tag along with the c:forEach tag and I was wondering if there's any progress being made on this issue? It appears from the last two comments and this bug's state that this issue is still open. I think Andreas' last post suggests a way to conform to the spec and still fix the memory leak. From perusing the code for the forEach tag, I believe a similar approach can be used to solve the same problem. The following "rules" (which are merely re-stating Andreas' last suggesting to something more general) could be applied to all tags in the jstl implementation: 1. If a tag has a reference that is in the AttSet, only set it to null in the release() method. 2. Otherwise, set it to null at the end of doEndTag. This would solve the memory leak that Andreas observed 2 years ago and it would solve the memroy leak I'm seeing in the forEach tag (there is a reference to "item" in the LoopTagSupport class that is not in the AttSet and keeping it around is causing my application some memory problems). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
