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