commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank W. Zammetti" <>
Subject Re: Digester wildcard question
Date Tue, 21 Jun 2005 03:59:16 GMT
Good call, making the methods non-static solved the problem.

I'm not sure how I feel about leaving it like that though, so I will go 
off and check out the other suggestions you offered... I actually just 
spent a few minutes playing with the CallMethodRule... I came up with 
what I thought was a clever and elegant solution, but it doesn't seem to 
work... I created the following class:

public class MyRule extends CallMethodRule {
   public MyRule() {
   public void body(String bodyText) throws Exception {
     String cem = digester.getCurrentElementName();
     methodName = "set" + cem.substring(0, 1).toUpperCase() + 

And I did:

digester.addRule("config/?", new MyRule()); the calling code.  I got an exception that doesn't seem to make 

SEVERE: End event threw exception
java.lang.NoSuchMethodException: No such accessible method: setItem1() 
on object
: jwp.sampleapp.SampleAppConfigBean

I thought it might be the same kind of static vs. non-static thing, but 
I've tried the methods both static and non-static, made no difference.

I'm about ready to "give up" and just leave the methods non-static... 
because the bean being populated stores static condfiguration 
information though, it would be nicer to not have to instantiate it to 
get at the config info.  But. it's not the end of the world or anything. 
  But if you have any ideas about why the above didn't work, maybe there 
is still a chance of not having to do that.

I will look at SetNestedPropertiesRule in a bit too, haven't got around 
to that yet.


Simon Kitching wrote:
> 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...
> Regards,
> Simon
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies

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

View raw message