commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [beanutils] bug#17036 PropertyUtils doesn't recognise "normal" properties on a DynaBean
Date Wed, 26 Mar 2003 18:19:46 GMT
On Tuesday, March 25, 2003, at 11:56 PM, Craig R. McClanahan wrote:

> On Tue, 25 Mar 2003, robert burrell donkin wrote:
>> Date: Tue, 25 Mar 2003 23:12:56 +0000
>> From: robert burrell donkin <>
>> Reply-To: Jakarta Commons Developers List <commons-
>> To: Jakarta Commons Developers List <>
>> Subject: [beanutils] bug#17036 PropertyUtils doesn't recognise "normal"
>>     properties on a DynaBean
>> PropertyUtils doesn't recognise "normal" properties on a DynaBean (see
>> can anyone think of any good reasons why i shouldn't change beanutils so
>> that normal properties are available if none of the dynabean properties
>> match?
> Personally, I think that doing this would be *really* confusing.  Just for
> one example, consider how one determines the names of all the properties
> supported by a DynaBean instance:
>   DynaProperty properties[] = dynaBean.getDynaClass().getDynaProperties()
> ;
> In today's implementation, the set of properties you get back represents
> 100% of the set of things that can be manipulated via get() and set()
> calls -- and you will get IAE if you try them with any other name.  If you
> make the proposed change, that's no longer the case -- but it is hard to
> argue that we should synthesize DynaProperty instances for the "real" bean
> properties as well, because they are *not* dynamic properties.

i think i agree with the argument that DyanClass to work correctly, the 
DynaProperty's returned should accurately represent all the properties 
that the DynaBean possesses. i also agree that synthesizing DynaProperty 
for the standard properties is probably going to lead to more problems 
than it solves.

> A second confusion relates to whether or not sets through the standard
> bean setter can be read by the dynamic getter, and vice versa:
>   dynaBean.set("foo", "bar");
>   dynaBean.setFoo("baz");
>   String whatDoYouGet = (String) dynaBean.get("foo");
>   // What do you get?
> Logically, you would want to require that this return "baz" -- but that
> means we would break every existing DynaBean implementation class that
> already exists.  If you don't require this, then it's going to lead to all
> sorts of bugs when users assume that it works that way.

> I don't like it.  If you want to manipulate the standard JavaBeans
> properties of a DynaBean implementation, you should just call them
> directly :-)  or else use reflection yourself.


i'll mark this one as WONTFIX

- robert

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message