You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by bu...@apache.org on 2003/12/02 01:10:29 UTC
DO NOT REPLY [Bug 25125] -
Violation of JSP spec: release() method and pageContext + parent
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25125>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25125
Violation of JSP spec: release() method and pageContext + parent
martinc@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
------- Additional Comments From martinc@apache.org 2003-12-02 00:10 -------
No, it's not a violation of the spec. The intent of the text you quoted is that
the container is not allowed to assume anything about the value of any property
after release() is invoked. That does not mean that the values must be reset,
just that the contain can make no assumptions. In fact, IMO, it would be a very
bad idea for custom tag handlers to be explicitly setting the values of
(protected) data members that they do not "own".
Also note that the release() method is not required to be called at all until
the tag handler is no longer required by the container. In particular, the
release() method need not be called between different uses of the same pooled
tag handler. So even if parent and pageContext were reset explicitly in reset
(), that is unlikely to be called until the tag handler is being released by
the container.
The scenario you describe sounds like a bug in the container. Why would there
be thousands of idle tag handlers in the first place? Perhaps you should submit
a bug report against whatever container you are using instead.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org