commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gabriele Carcassi" <>
Subject Re: digester: can SetPropertyRule warn on not found properties?
Date Wed, 08 Sep 2004 13:35:19 GMT
I think I have a good sense of what is acceptable. I'll be back when I can 
come up with something reasonable. Not sure when... (I have some deadlines 
coming) but it's something I'd really like to have, so it's likely that I'll 
postpone something else sooner or later... :-)

Thanks again,

"Craig McClanahan" <> wrote in message
> On Wed, 08 Sep 2004 10:16:22 +1200, Simon Kitching
> <> wrote:
>> On Wed, 2004-09-08 at 05:05, Gabriele Carcassi wrote:
>> > Hi Simon and Robert,
>> >
>> > Thanks for the answers.
>> >
>> > I had a look at the source and it seems that in dev an exception is 
>> > thrown:
>> >
>> > but it doesn't seem to block the Digester processing... anyway, I don't
>> > think I will have problem finding why.
>> >
>> > Once I am done, would you like the patch to be contributed back? If so, 
>> > is
>> > it ok if it depends on the latest version of beanutil?
>> Yes, a patch for Digester would be great. If it is necessary to patch
>> beanutils, then I can't speak for the beanutils developers (which is
>> mostly Robert) but think that a patch for this would also be happily
>> accepted as long as it doesn't break backward compatibility.
>> Having digester depend on an unreleased beanutils is a problem; it means
>> that the next version of Digester could not be released until the next
>> version of beanutils is released. However (optionally) having errors
>> reported for attributes without matching bean properties is a nice
>> feature, so I'm personally willing to consider this. Maybe there is some
>> reflection trick that can be done so that when digester is run with an
>> older beanutils release this feature is just not available?
>> Regards,
>> Simon
> If throwing exceptions in the setProperties() or copyProperties()
> methods are ever implemented in BeanUtils, this is going to have to be
> a feature that can be turned on and off, and default to off (for
> backwards compatibility).  It will totally break existing uses of
> these methods (such as the way that Struts uses them to populate form
> beans), where there is implicit reliance on the current silence when
> an HTTP parameter has a specified value but there's no corresponding
> form bean property.
> Craig 

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

View raw message