Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
From: bugzilla@apache.org
To: tomcat-dev@jakarta.apache.org
Subject: DO NOT REPLY [Bug 38197]  - taglib pool bug when tag is used with
 jsp:attribute
In-Reply-To: <bug-38197-78@http.issues.apache.org/bugzilla/>
Message-Id: <20071205181653.0F471714241@brutus.apache.org>
Date: Wed,  5 Dec 2007 10:16:52 -0800 (PST)

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


dbelfer@sminter.com.ar changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|VERIFIED                    |REOPENED
         Resolution|INVALID                     |


------- Additional Comments From dbelfer@sminter.com.ar  2007-12-05 10:16 -------
Well it has been a while since I reported this.  I am not sure the current
status of the implementation right now. At the time I checked the code, there
was a bug in the way of picking the pooled instance, and since it was closed as
invalid I will assume it was not fixed.

>From the JSP spec:
"The JSP container may reuse classic tag handler instances for multiple
occurrences of the corresponding custom action, in the same page or in different
pages, but only if the same set of attributes are used for all occurrences. If a
tag handler is used for more than one occurence, the container must reset all
attributes where the values differ between the custom action occurrences. If an
attribute value is set as a request-time attribute value (using a scripting or
an EL expression), the container must reset the attribute between all reuses of
the tag handler instance ..."


The pool implementation is using attributes specified in the basic way for
selecting a pooled instance. I mean:

<mytag attr="1"/>

But it is not considering the alternate way of specifying an attribute

<mytag>
<jsp:attribute name="attr">1</jsp:attribute>
</mytag>


>From the spec:
"The <jsp:attribute> action must only be used to specify an attribute value for
standard or custom actions."

So <jsp:attribute> is valid way of specifying an attribute for a custom action
and TagLibs are actions, therefore, the container should use attributes defined
by this mean when selecting the pooled instance.

In the example code I posted originally (when I reported the bug), the same
instance of the TagHandler is used, and although the attributes set differs,
those attributes are not reset as the specification states.
For the way the pool is implemented, a different instance should be used because
an additional attribute is specified.

As a conclusion, if a properly developed TagHandler is used and one of its
attributes is specified using <jsp:attribute>, which is completely valid, the
obtained result could be wrong due to the way the Pool is implemented.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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