On Wed, 9 Jul 2003, Craig R. McClanahan wrote: > On Wed, 9 Jul 2003, Arun Thomas wrote: > > > Date: Wed, 9 Jul 2003 16:28:07 -0700 > > From: Arun Thomas <[EMAIL PROTECTED]> > > Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > > To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > > Subject: RE: cvs commit: > > jakarta-commons/beanutils/src/test/org/apache/commons/beanutils > > PropertyUtilsTestCase.java TestBean.java > > > > I'm confused as to what part of Section 8.3.1 of the Java Beans spec > > defines this behaviour. I'm looking at version 1.01 - is there a newer > > revision? > > > > No ... that's the most current. > > > <quote> > > By default, we use design patterns to locate properties by looking for methods of > > the form: > > public < PropertyType> get< PropertyName>(); > > public void set< PropertyName>(< PropertyType> a); > > If we discover a matching pair of "get<PropertyName>" and "set<PropertyName>" > > methods > > that take and return the same type, then we regard these methods as defining a > > read-write property whose name will be "<propertyName>". We will use the > > "get<PropertyName>" method to get the property value and the "set<PropertyName>" > > method to set the property value. The pair of methods may be located either in the > > same class or one may be in a base class and the other may be in a derived class. > > > > If we find only one of these methods, then we regard it as defining > > either a read-only or a writeonly property called "<propertyName>" > > > > This is the key sentence. The introspection code will find getFoo() and > isFoo() that return boolean and pick isFoo(), but they won't find > setFoo(boolean). Therefore, the JDK thinks that there is a read-only > boolean property named foo.
I believe that you wanted to say `they won't find setFoo(String)`, because the introspection code should find setFoo(boolean) and see foo as a read-write property. > It would have made more sense to me for introspection to decide that there > was no property at all because of the type mismatch on the setter, but > alas that is not the way it actually works, so it's nothing BeanUtils can > really do anything about anyway (i.e. I will veto any suggestion that > BeanUtils define properties in any way different than what the standard > JDK introspection does). > > > By default we assume that properties are neither bound nor constrained (see > > Section 7). > > So a simple read-write property "foo" might be represented by a pair of methods: > > public Wombat getFoo(); > > public void setFoo(Wombat w); > > </quote> > > > > Section 8.3.2 goes on to note that is<propertyName>, if present, will be > > used preferentially for boolean properties. > > > > However, at least this text does not specify what happens if the > > setMethod takes a different type than the get method returns. There is > > nothing that suggests the get/is method has precedence over the set > > method. > > > > Am I missing something (either here, or in the spec)? > > > > I don't see anything explicit in the spec either ... all I see is what > JDKs actually do. > > > -AMT > > Craig > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Sent: Thursday, July 03, 2003 12:10 PM > > To: [EMAIL PROTECTED] > > Subject: cvs commit: > > jakarta-commons/beanutils/src/test/org/apache/commons/beanutils > > PropertyUtilsTestCase.java TestBean.java > > > > > > craigmcc 2003/07/03 12:10:27 > > > > Modified: beanutils/src/test/org/apache/commons/beanutils > > PropertyUtilsTestCase.java TestBean.java > > Log: > > Add a unit test to verify the current JDK introspection of a bean with > > the following method signatures: > > > > public boolean isFoo(); > > public boolean getFoo(); > > public void setFoo(String foo); > > > > According to Section 8.3.1 of the JavaBeans Specification, this > > will get recognized as a read-only boolean property using "isFoo" > > as the getter method. Therefore, all of the code in commons-beanutils > > should make this same assumption as well. > > > > One could argue that it would make more sense to not recognize "foo" > > as a property at all, since the types on the getter and setter methods > > are different. However, that's not the way the JavaBeans spec is worded, > > and not the way that the JDK's introspection logic works either. > > > > Revision Changes Path > > 1.31 +31 -4 > > jakarta-commons/beanutils/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java > > > > Index: PropertyUtilsTestCase.java > > =================================================================== > > RCS file: > > /home/cvs/jakarta-commons/beanutils/src/test/org/apache/commons/beanutils/PropertyUtilsTestCase.java,v > > retrieving revision 1.30 > > retrieving revision 1.31 > > diff -u -r1.30 -r1.31 > > --- PropertyUtilsTestCase.java 12 May 2003 21:42:56 -0000 1.30 > > +++ PropertyUtilsTestCase.java 3 Jul 2003 19:10:27 -0000 1.31 > > @@ -452,6 +452,33 @@ > > > > > > /** > > + * <p>Negative tests on an invalid property with two different boolean > > + * getters (which is fine, according to the JavaBeans spec) but a > > + * String setter instead of a boolean setter.</p> > > + * > > + * <p>Although one could logically argue that this combination of method > > + * signatures should not identify a property at all, there is a sentence > > + * in Section 8.3.1 making it clear that the behavior tested for here > > + * is correct: "If we find only one of these methods, then we regard > > + * it as defining either a read-only or write-only property called > > + * <em><property-name></em>.</p> > > + */ > > + public void testGetDescriptorInvalidBoolean() throws Exception { > > + > > + PropertyDescriptor pd = > > + PropertyUtils.getPropertyDescriptor(bean, "invalidBoolean"); > > + assertNotNull("invalidBoolean is a property", pd); > > + assertNotNull("invalidBoolean has a getter method", > > + pd.getReadMethod()); > > + assertNull("invalidBoolean has no write method", > > + pd.getWriteMethod()); > > + assertTrue("invalidBoolean getter method is isInvalidBoolean", > > + "isInvalidBoolean".equals(pd.getReadMethod().getName())); > > + > > + } > > + > > + > > + /** > > * Positive getPropertyDescriptor on property <code>longProperty</code>. > > */ > > public void testGetDescriptorLong() { > > > > > > > > 1.16 +35 -4 > > jakarta-commons/beanutils/src/test/org/apache/commons/beanutils/TestBean.java > > > > Index: TestBean.java > > =================================================================== > > RCS file: > > /home/cvs/jakarta-commons/beanutils/src/test/org/apache/commons/beanutils/TestBean.java,v > > retrieving revision 1.15 > > retrieving revision 1.16 > > diff -u -r1.15 -r1.16 > > --- TestBean.java 1 Feb 2003 07:45:29 -0000 1.15 > > +++ TestBean.java 3 Jul 2003 19:10:27 -0000 1.16 > > @@ -525,6 +525,37 @@ > > } > > > > > > + // ------------------------------------------------------ Invalid Properties > > + > > + > > + /** > > + * <p>An invalid property that has two boolean getters (getInvalidBoolean > > + * and isInvalidBoolean) plus a String setter (setInvalidBoolean). By the > > + * rules described in the JavaBeans Specification, this will be considered > > + * a read-only boolean property, using isInvalidBoolean() as the getter.</p> > > + */ > > + private boolean invalidBoolean = false; > > + > > + public boolean getInvalidBoolean() { > > + return (this.invalidBoolean); > > + } > > + > > + public boolean isInvalidBoolean() { > > + return (this.invalidBoolean); > > + } > > + > > + public void setInvalidBoolean(String invalidBoolean) { > > + if ("true".equalsIgnoreCase(invalidBoolean) || > > + "yes".equalsIgnoreCase(invalidBoolean) || > > + "1".equalsIgnoreCase(invalidBoolean)) { > > + this.invalidBoolean = true; > > + } else { > > + this.invalidBoolean = false; > > + } > > + } > > + > > + > > + > > // ------------------------------------------------------- Static Variables > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
