DO NOT REPLY [Bug 25623] - The forEach JSTL tag doesn't release items

[bu...@apache.org]

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=25623>.
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=25623

The forEach JSTL tag doesn't release items





------- Additional Comments From justyna.horwat@sun.com  2004-06-15 21:24 -------
>From the tag author's point of view I believe that the JSTL tag handler's are doing the right thing. In the 
forEach tag, the release method sets the items to null. The tag handler instance can be reused if tag 
pooling is enabled and if another custom action uses the same set of attributes. 

The strut's tags explicitly set items to null in the doEndTag() method. The struts implementation 
violates the tag pooling contract and can end up needlessly destroying and creating items between 
invocations of doStartTag and doEndTag.

Now, on to how the container manages the jsp lifecycle and when release is actually called. If you look 
at the Tomcat 5 jasper (jsp) implemenation you will see a Generator that generates the java servlet 
source code given a jsp. This Generator creates a _jspDestroy() method. Here is the method from one of 
my generated servlet files:

----
  public void _jspDestroy() {
    _jspx_tagPool_c_out_value_nobody.release();
    _jspx_tagPool_c_out_value_escapeXml_nobody.release();
  } 
----

When _jspDestroy() is invoked it calls all the tag handlers in the pool and tells them to invoke their 
release methods.

Now on to when the _jspDestroy() method is invoked. Every servlet that was generated from a jsp page 
extends org.apache.jasper.runtime.HttpJspBase. The HttpJspBase has a destroy() method that invokes 
_jspDestroy(). HttpJspBase.destroy() is invoked whenever Servlet.destroy() is and follows the servlet 
lifecycle.

Now on to the tricky part, the container itself determines when the servlet will be taken out of service 
and can do so for various reasons. It would be difficult to determine when it has done so and when the 
object references are actually freed. It would be interesting to see your profiler results when using a 
different container.

There is a good discussion on container behavior, lifecycle, and tag pooling available in this bug report:

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16001

If you find that you are having issues as a result of the container tag pooling, uou can turn it off in 
Tomcat by setting the init parameter "enablePooling" to "false" in your global $CATALINA_BASE/conf/
web.xml.

This issue seems more in the realm of the container and how it manages objects and tag pools.

---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-dev-help@jakarta.apache.org