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. 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]
