tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 16808] New: - Jasper makes calls to tag setters that 1.2 spec says it doesn't have to
Date Wed, 05 Feb 2003 17:22:02 GMT
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=16808>.
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=16808

Jasper makes calls to tag setters that 1.2 spec says it doesn't have to

           Summary: Jasper makes calls to tag setters that 1.2 spec says it
                    doesn't have to
           Product: Tomcat 4
           Version: 4.1.8
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Enhancement
          Priority: Other
         Component: Jasper 2
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: dmkarr@earthlink.net


The JSP 1.2 specification, in section JSP.10.1, titled "Simple Tag Handlers", in
a subsection titled "Properties", has the following statement:

Once properly set, all properties are expected to be persistent, so that if the
JSP container ascertains that a property has already been set on a given tag
handler instance, it needs not set it again. User code can access property
information and access and modify tag handler internal state starting with the
first action method (doStartTag) up until the last action method (doEndTag or
doFinally for tag handlers implementing TryCatchFinally).

I've discoverered Tomcat is not taking advantage of the fact that it doesn't
need to call the setter method again on the reused tag handler.

Following this is a simple excerpt from my test case, using Struts and
Struts-EL.  I find that the "setValue()" method is called on the first
iteration, which is expected, but it is also called on the second iteration,
which is not necessary.

      <logic-el:iterate collection="${testbean.stringArray}" id="foo"
                        indexId="ctr">
       <td>
        <html-el:text name="testbean" property="stringIndexed" value="${foo}"
                      indexed="true"/>
       </td>
      </logic-el:iterate>

This might be considered just an optimization issue, but the lack of this
optimization led me down an unfortunate road, due to a mistake I made.

I wrote all of the tag classes in the Struts-EL library under the mistaken
assumption that I could safely modify attribute values.  Making this assumption
made it very convenient, as I could subclass from the Struts tag classes, and
just use the getter/setter methods for the attributes in the base class, without
having to add redundant attributes to the derived class.  After the container
calls the setter on the attribute (say with a value of "${foo}"), in the
"doStartTag()" of the Struts-EL tags, I use the JSTL EL engine to evaluate the
attribute value and send it back to the setter method of the attribute.

This works fine in Tomcat, which made me confident that I had followed all the
rules, as I know that Tomcat is the reference implementation of the specification.

Unfortunately, the Resin web container takes advantage of this optimization, so
that reused tag handlers won't get the setter methods called, so the attribute
values will be the same as what I got from running the EL engine on the initial
instance, making the page and tag library quite broken.

I know how to fix this in my tag library, but it will require a lot of
straightforward coding.

>From one point of view, this should only be considered an enhancement, but I
think this is a little different from other optimization opportunities.

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


Mime
View raw message