Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Date: Sat, 23 Nov 2002 10:57:27 -0800 (PST)
From: "Craig R. McClanahan" <craigmcc@apache.org>
To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>,
    Jim Cobban <jcobban@magma.ca>
cc: Jan Luehe <Jan.Luehe@Sun.COM>
Subject: Re: Why can I not use attributes "lang" and "maxRows" in a custom
 tag
In-Reply-To: <000e01c2930b$df1035a0$6201a8c0@magma.ca>
Message-ID: <20021123104836.B26999-100000@icarus.apache.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On Sat, 23 Nov 2002, Jim Cobban wrote:

> Date: Sat, 23 Nov 2002 11:17:50 -0500
> From: Jim Cobban <jcobban@magma.ca>
> Reply-To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>,
>      Jim Cobban <jcobban@magma.ca>
> To: Jan Luehe <Jan.Luehe@Sun.COM>
> Cc: tomcat-dev@jakarta.apache.org
> Subject: Re: Why can I not use attributes "lang" and "maxRows" in a
>     custom tag
>
> ----- Original Message -----
> From: "Jan Luehe" <Jan.Luehe@Sun.COM>
> Subject: Re: Why can I not use attributes "lang" and "maxRows" in a custom
> tag
>
>
> > > Tomcat 4.1.12 does not accept a custom tag with attributes "lang"
> > > or "maxRows".  When I asked about this on the Tomcat users list I was
> > > informed that it also does not accept the attribute "class".
> > >
> > > Specifically if I define those attributes then when the jsp is compiled
> I
> > > get an "unable to find setter" error.  If I replace them with similar
> but
> > > meaningless attribute names the page compiles correctly.
> >
> > This can't be true. For example, JSTL defines an attribute
> > named 'maxRows' for its <sql:query> action.
> > I am not aware of any naming restrictions for custom tag attributes.
> >
> > Are you sure the tag handler for your custom action
> > defines an approriate setter method for the attributes in
> > question?
>
> I kept experimenting and found exactly what it was that Tomcat disliked
> about my attribute.  It was not the name.  It was not the presence or
> absence of the set method.  It was that there was also a get method which
> did not return String!  Since Tomcat does not use the get method I do not
> understand why it cares whether or not one is present or what its signature
> is.  But as soon as I change the name of the get method so it did not match
> the set method Tomcat merrily accepted the tag.

Tomcat cares because JSP custom tags are required to implement the
standard JavaBean naming patterns for property-related methods, as defined
in the JavaBeans Specification.

  http://java.sun.com/products/javabeans/

>
> For me this is now an issue of documentation.  I have searched the JSP 1.2
> spec using every term I can think of and I cannot find where it specifies
> the characteristics of the set method for an attribute on a custom tag.  I
> have therefore been depending upon the description of this capability in
> Marty Hall's book.  If the JSP specification, and Tomcat, have a legitimate
> reason for looking at the characteristics of the get method when deciding
> whether or not to use the set method, then that should be documented.
> Otherwise the behavior is frankly mysterious.

In the JSP 1.2 spec, section JSP.10.1:

    "A tag handler has some properties that are exposed to
    the page as attributes on an action; these properties
    are managed by the JSP container (via generated code).
    The setter methods used to set the properties are discovered
    using the JavaBeans introspector machinery."

The last sentence refers to the java.beans.Introspector class, which
refers you to the JavaBeans spec.

>
> Thank you for responding.  When a week went by without a response I
> unsubscribed from the list, so the CC on this message may be discarded.
>

Craig


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