Re: Why can I not use attributes lang and maxRows in a custom tag

2002-11-23 Thread Jim Cobban
- 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]




Re: Why can I not use attributes lang and maxRows in a custom tag

2002-11-23 Thread Robert_McDermid

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]




Re: Why can I not use attributes lang and maxRows in a custom tag

2002-11-23 Thread Jim Cobban
- Original Message -
From: Craig R. McClanahan [EMAIL PROTECTED]
Subject: Re: Why can I not use attributes lang and maxRows in a custom
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 the pointers.  I appreciate that exploiting the existing
support for Beans is the obvious way for Tomcat to acquire this information
about the class, even if Tomcat never uses the get method.  I merely hope
that the documentation can be improved to be a little less obscure so that
other programmers like myself, who do not have the time to become intimately
familar with all aspects of Java technology, can be brought up to speed with
less wasted effort.


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




Re: Why can I not use attributes lang and maxRows in a custom tag

2002-11-23 Thread Paul Speed
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]




Re: Why can I not use attributes lang and maxRows in a custom tag

2002-11-22 Thread Jan Luehe
Jim,

 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?


Jan



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




Why can I not use attributes lang and maxRows in a custom tag

2002-11-19 Thread Jim Cobban
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.

I have searched the JSP 1.2 and Tomcat 4 documentation exhaustively and I cannot find 
any indication that these attributes are not allowed.  The names I want are the ones I 
feel will be most intuitive to my users. The lang keyword is to be used to specify 
the natural language of the interface and the maxRows attribute is to be used to 
specify the maximum number of rows from a database query which are to be displayed.

I really want to use these attribute names.  If there is a list of forbidden attribute 
names this should be documented somewhere.

Jim Cobban   [EMAIL PROTECTED]
34 Palomino Dr.
Kanata, ON, CANADA
K2M 1M1
+1-613-592-9438