Re: DO NOT REPLY [Bug 16749] - Struts EL tag handlers cannot be reused by containers

[Mark Abbott <Ma...@openwave.com>]

And presumably the container is required to call setters
on any attribute that is marked as rtexprvalue in the
tld, when reusing a handler.

I always stick to a very simple procedure when writing handlers,
that matches what Craig said below: only modify the values
of the variables set by setter methods in the setters themselves
or in the release method.  If some other part of the tag
execution needs to change this value, then at the beginning of
doStartTag you copy the set value into another instance variable
and work with that in all the doX methods.  This is safe because
you are guaranteed single threading through all the doX methods
by the spec.

    Mark

At 09:24 AM 2/4/2003, Craig R. McClanahan wrote:


>On Tue, 4 Feb 2003 bugzilla@apache.org wrote:
>
>>
>> Struts EL tag handlers cannot be reused by containers
>>
>
>It sounds like these tags definitely have a problem.  There's been some
>recent discussion on TOMCAT-USER about designing tags that work reusably
>as well.
>
>The bottom line:
>
>* The container can reuse instances of tag handlers
>  when it sees that exactly the same set of attributes
>  is used (not necessarily the same values).
>
>* This kind of reuse can happen whether or not the
>  container implements "tag pooling".
>
>* When a tag handler instance is reused, the JSP page
>  compiler can decide if it has already set a particular
>  property on that instance, and omit the second set call.
>  For example, in:
>    <foo:bar a="1" b="2/>
>    <foo:bar a="1" b="3"/>
>  The second setA() call can be omitted, since the container
>  knows that it already called setA("1") the first time.
>
>* If a tag instance is going to be reused, the doEndTag()
>  call on the first use is going to be followed by the
>  doStartTag() call of the second use.  Any per-use cleanup
>  activity needs to happen at the end of doEndTag().
>
>* The net effect of all this is an important restriction -- it's
>  not legal for a tag handler to modify the values stored by
>  the setter calls from the page, *anywhere* in the path from
>  doStartTag() through doEndTag().
>
>* The container will call release() after it has used the
>  instance for the last time.
>
>Craig
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-dev-help@jakarta.apache.org


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

Re: DO NOT REPLY [Bug 16749] - Struts EL tag handlers cannot be reused by containers

[Mark Abbott <Ma...@openwave.com>]

BTW, the procedure I described breaks down in
exactly the situation faced by the Struts EL tags,
or any other tag handlers that subclass other handlers.
This is because the superclass methods are directly 
referencing the private instance variables that contain
the set attribute values.  A subclass has no way to 
affect the behavior of the superclass by modifying the 
interpretation of attribute values, other than what it can
do by overriding the setter method, which is often not
sufficient.

To make a handler subclassable but still reusable, you
have to make sure you only access attribute variables 
via getter methods that subclasses can override.

      Mark


At 09:35 AM 2/4/2003, Mark Abbott wrote:
>And presumably the container is required to call setters
>on any attribute that is marked as rtexprvalue in the
>tld, when reusing a handler.
>
>I always stick to a very simple procedure when writing handlers,
>that matches what Craig said below: only modify the values
>of the variables set by setter methods in the setters themselves
>or in the release method.  If some other part of the tag
>execution needs to change this value, then at the beginning of
>doStartTag you copy the set value into another instance variable
>and work with that in all the doX methods.  This is safe because
>you are guaranteed single threading through all the doX methods
>by the spec.
>
>    Mark


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