It also interacts with tag reinitialization as described here:
https://issues.apache.org/bugzilla/show_bug.cgi?id=49589
in that we hang on to the value when the tag is in the pool only to clear it
when we use it.
I think there are other optimizations that could be done to forEach but have
not gotten around to looking for them.
On Jan 27, 2011, at 8:54 AM, Christopher Schultz wrote:
> All,
>
> Today's (duplicate) bug report about held references in JSTL tags has me
> thinking. What is the resistance to "fixing" the problem of object
> retention in these tags?
>
> JSP 1.8.2 says that all page-scoped objects are released after the
> response is written or the request is forwarded to another handler.
> Doesn't that mean that something like this:
>
> <c:set var="foos" />
>
> <c:forEach var="foos" items="$foos">
> ...
> </c:forEach>
>
> will violate the spec by holding-on to the "foos" list indefinitely
> instead of flushing it after the response has been sent?
>
> I mean, I certainly understand the complaints being filed in BZ because,
> hey, the tags are holding onto these references and potentially eating
> up lots of memory.
>
> On the other hand, what's the resistance on the Tomcat side to "fixing"
> this? I can think of a couple of reasons:
>
> 1. This is a spec-compliance issue and the stance of the Tomcat team is
> that releasing these references violates the spec, and so it won't be done.
> 2. It's easy to disable tag pooling via configuration, which has the
> same effect as nulling all the data in these tag handlers. Since it's
> easy to disable tag pooling, there is no need to modify anything.
> 3. Nobody feels like writing a patch.
>
> I'd love to hear some comments.
>
> Thanks,
> -chris
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
