The Java beans API requires getters.  It does not require setters.
No setter means the property is read-only.  There's no such thing as
write-only in the Java beans API.

A getter is the only way to determine what the type of the property
is since there can be only one getter with a particular name.  The 
Java beans API is all about deducing all of this information at 
runtime... so it must be able to figure this out. (For 
PropertyDescriptors and such.)

Not 100% useful as a way to do simple reflection though.
-Paul

[EMAIL PROTECTED] wrote:
> 
> If Tomcat uses the "beans" API in Java to do the reflection for calling
> these methods, then that is probably why.
> It insists on having a valid get and set method for an attribute for some
> reason.  I ran into this once when I only wanted
> to have "getters" with no setters, and I couldn't find a way around it
> other than to use reflection directly (mind you,
> I was in a hurry, so I didn't try too hard).
> 
> -- Rob
> 
> 
>                       "Jim Cobban"
>                       <[EMAIL PROTECTED]        To:       "Jan Luehe" 
><[EMAIL PROTECTED]>
>                       >                        cc:       
><[EMAIL PROTECTED]>
>                                                Subject:  Re: Why can I not use 
>attributes "lang" and "maxRows" in a custom tag
>                       23/11/2002 11:17
>                       AM
>                       Please respond to
>                       "Tomcat
>                       Developers List"
> 
> 
> 
> ----- Original Message -----
> From: "Jan Luehe" <[EMAIL PROTECTED]>
> 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.
> 
> 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.
> 
> 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.
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]
> >
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]
> >
> 
> If you received this e-mail in error please delete it and notify the sender as soon 
>as possible. The contents of this e-mail may be confidential and the unauthorized 
>use, copying, or dissemination of it and any attachments to it, is prohibited.
> 
> Internet communications are not secure and Hyperion does not, therefore, accept 
>legal responsibility for the contents of this message nor for any damage caused by 
>viruses. The views expressed here do not necessarily represent those of Hyperion.
> 
> For more information about Hyperion, please visit our Web site at www.hyperion.com
> 
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to