commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <>
Subject Re: [beanutils] Summary of propsed/committed changes for Bugs
Date Mon, 12 Jul 2004 03:37:15 GMT
Niall Pemberton wrote:

>4) Bug 23815, 26904 and 29571
>Bug 23815   PropertyUtils.getNestedProperty() doesn't allow getXxxx on
>Map-Instances any longer
>Bug 26904  (g|s)etSimpleProperty fails when passing a Map
>Bug 29571  Inconsistent behaviour of BeanUtils.setProperty() and
>BeanUtils.getProperty() methods
>These bugs all related to the same issue. Craig McClanahan posted concerns
>in one of the bugs that what was being requested would break backward
>compatibility. I believe that the change in behaviour I'm proposing
>satisfies both camps and resolves the inconsistencies between some of the
>methods. I've documented on Bug  23815 the changes in behaviour to
>PropertyUtilsBean I'm proposing.

Thanks for taking the time to propose a solution to this problem, as 
well as all the work you've done on the other BeanUtils issues.  As I 
just posted in the comments on bug 23815, I'm deeply concerned that 
changing this behavior will break Struts 1.1 apps (yes, I know that 
people only now converting from Struts 1.0 would find it easier; but 
it's the Struts 1.0 behavior that was badly broken).  What's worse is 
the fact that this isn't the only case where a map is treated specially 
-- exactly the same thing happens with the standard implementations of 
dynabeans (including DynaActionForm in Struts 1.1).

The standard implementations of expression evaluation (JSTL 1.0/1.1, JSP 
2.0, JSF 1.0/1.1) all conform to the way that BeanUtils currently works 
-- if the object you pass implements Map, it is *always* treated as a 
Map.  This is further evidence that the right path for default behavior 
lies in maintaining what we currently have, not going back to what was 

For making the Struts 1.0 transition easier, I'd be +1 on setting up a 
BeanUtilsFactory that allows you to set the characteristics of the 
BeanUtils instance to be created (somewhat like what JAXP does to set up 
a parser instance that is either validating or non-validating, for 
example).  But I'm -1 on changing the default behavior of these methods 
until we do the beanification step.


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

View raw message