commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: Digester wildcard question
Date Tue, 21 Jun 2005 02:38:03 GMT
Hi Frank,

On Mon, 2005-06-20 at 22:13 -0400, Frank W. Zammetti wrote:
> ...and here is that class I'm trying to populate...
> public class SampleAppConfigBean {
>    private static String item1;
>    private static String item2;
>    private static String item3;
>    public static void setItem1(String val) {
>      item1 = val;
>    }

> Now, it sure looks to me like that bean has an item1 property :) 

I'm guessing that the fact that the method is static is where the
problem lies, because everything else looks good. The
BeanPropertySetterRule really does expect the target properties to be
valid javabean properties, which is different from there just being a
setter method. Unfortunately Sun haven't clearly documented exactly what
the rules are for javabean properties (at least anywhere I can find).

You could try writing a trivial test class which calls
java.beans.Introspector.getBeanInfo(SampleAppConfigBean) and see what
java tells you the available bean properties are.

I bet that setItem1 etc are not reported - and that if you make the
methods non-static that they will be.

If this is the case, and you really need these methods to be static then
you could resort to using CallMethodRule instead of
BeanPropertySetterRule, as CallMethodRule doesn't require its targets to
comply with the javabean rules.

Have you had a look at the SetNestedPropertiesRule? As its javadoc
describes, it should handle the problem you have but with the standard
RulesBase class (though it does require the target is a property like
BeanPropertySetterRule does). Either approach is ok though...



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

View raw message