commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: Digester yielding IllegalAccessException in CallMethodRule, SetNextRule
Date Wed, 05 Dec 2001 19:14:20 GMT
On Wednesday, December 5, 2001, at 06:02 PM, Craig R. McClanahan wrote:


> The key is that the third argument to addSetNext() has to match the
> method's signature, because this is what is used to do the reflection
> lookup.  The object on the top of the stack (a StandardHost in the example
> above) need only be assignment-compatible with that signature for this to
> work.
> Is this the case you're talking about?

no. at the moment, you have to specify the third parameter in order to 
make the digestion work.
this isn't too much of limitation - once you know how to do it, it's just 
a bit of extra typing.

where it becomes a bit more restrictive is when you use a general matching 
rule (like '*'). for example you might have a naming scheme where all 
child objects are added by calling addChild on the parent. you can write a 
single general rule only when either each class has an addChild method 
that takes a specific interface (xxx.yyy.zzz.Child, say). In this case, 
you can use something like

digester.addSetNext("*", "addChild", "xxx.yyy.zzz.Child);

you can also write a single general rule if every object has an exactly 
matching addChild method. In this case you can use

digester.addSetNext("*", "addChild");

if your object model doesn't follow one of these two patterns, then even 
if each object has a method with the right name with an 
assignment-compatible parameter then the digestion won't work.

i'm not suggesting that this is killing functionality but it'd be nice to 
have if there was an appropriate method finder available...

>> jason came across a similar issue with his automatic mapper but it meant
>> that he ended up using indexed properties rather than calling an addXXX
>> method for children (since beanutils will find an indexed property but 
>> not
>> a name single parameter method). unfortunately, using indexed properties
>> means that writing a digester-powered version is not realistic.
>> i was wondering whether code to do this kind of single parameter method
>> finding would fit as part of propertyutils.
> PropertyUtils itself is focused only on finding property getters and
> setters.  But some general utility classes to make some of the really
> strange things with Java reflection easier to use (for example, finding a
> "compatible" Method rather than just an exact-match Method) would
> certainly fit into the overall "beanutils" package.

yes, you're right - PropertyUtils does seem like the wrong place. it does 
have a number of private utility methods which might be useful, i suppose 
that these could be moved out or given public access, though.

- robert

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

View raw message