On 21 Sep 2004, at 06:06, Simon Kitching wrote:
<snip>
I'm worried about this patch.
The existing code to actually do the assignment to properties calls BeanUtils.populate(...) which calls BeanUtilsBean.populate(...) which calls BeanUtilsBean.setProperty(...).
This patch however uses PropertyUtils.isWriteable to check for the existence of the property.
The two code paths are completely different, and I am concerned that they may consider different things to be valid properties.
that's true.
i couldn't see any harmful side effects when the variable is switched off and it is a solution (of sorts) to a quite a common problem amongst users (debugging rulesets). it's better than nothing but if anyone has an improved solution that would be great.
I would prefer to see either: (a) BeanUtils.populate modified to optionally throw an exception if a matching property can't be found, or
that would be better but problematic in other ways. configuration would need to be done properly.
the right way to do this would be to upgrade the beanutils to 1.7 and use have digester (and the other rules) use an instance of the bean (rather than the pseudo-singleton as present). for backwards compatibility, digester would default to the pseudo-singleton if no custom implementation has been specified when parsing starts. rules would use the digester's instance.
uses would then configure a beanutilsbean instance appropriately and then set that instance on digester.
if we are going to this level of trouble then it'd probably be worth factoring out a wrapper so that users can use whatever bean populator they wish.
(b) SetPropertiesRule be modified to use PropertyUtils methods to do the
property setting rather than BeanUtils.populate.
The latter is probably too risky a change to make; too much chance of breaking existing digester users like Struts.
+1
While I very much like this new feature, I am not convinced using PropertyUtils methods to implement it is safe.
it's probably safe-ish in that (in practice) it would be rare for them to disagree too much, just maybe not as useful as it might be. i'd be happy if we went for the more comprehensive solution but (if i were doing the coding) i'd want to be convinced that the effort was worth the gain. comments anyone?
- robert
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
