commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@apache.org>
Subject Re: Digester wildcard question
Date Tue, 21 Jun 2005 05:13:13 GMT
On Mon, 2005-06-20 at 23:59 -0400, Frank W. Zammetti wrote:
> 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() {
>      super("");
>    }
>    public void body(String bodyText) throws Exception {
>      String cem = digester.getCurrentElementName();
>      methodName = "set" + cem.substring(0, 1).toUpperCase() + 
> cem.substring(1);
>      super.body(bodyText);
>    }
> }
> 
> And I did:
> 
> digester.addRule("config/?", new MyRule());
> 
> ...in the calling code.  I got an exception that doesn't seem to make 
> sense...
> 
> 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 puzzled too. It's not terribly elegant but I don't see why it won't
work in your case.


> 
> 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.
> 

Rather than distort your design, I would suggest either:

(a)
Create your own Rule class based on the source for
BeanPropertySetterRule, but replacing all of the method lookup stuff
with a simple:
  Method m = Config.class.getMethod(xmlElementName);
  m.invoke(null, bodyText);
All your config methods seem to take strings so you don't need to worry
about type-conversion.

Digester is designed to allow custom rules to be written.

(b)
Turn your config object into a singleton. Instead of using
ObjectCreateRule, use FactoryCreateRule with a custom ObjectFactory
which simply returns the singleton object. It's still a change to your
design but not so radical.

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

It's probably only of theoretical interest in your case if you really
want static methods, as it does depend on BeanUtils.setProperty which
requires true bean properties and hence no static methods.

Regards,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message