commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: Digester yielding IllegalAccessException in CallMethodRule, SetNextRule
Date Wed, 05 Dec 2001 18:02:05 GMT

On Wed, 5 Dec 2001, robert burrell donkin wrote:

> Date: Wed, 5 Dec 2001 18:03:53 +0000
> From: robert burrell donkin <>
> Reply-To: Jakarta Commons Developers List <>
> To: Jakarta Commons Developers List <>
> Subject: Re: Digester yielding IllegalAccessException in CallMethodRule,
>      SetNextRule
> On Wednesday, December 5, 2001, at 06:40 AM, Craig R. McClanahan wrote:
> > On Tue, 4 Dec 2001, Donnie Hale wrote:
> <snip>
> >> Is it possible to
> >> implement an interface with methods which have package scope though the
> >> interface methods are public? I don't care that some unknown future
> >> entity
> >> implements the interface; but I don't want the methods in the
> >> implementation
> >> of it that I care about to be publicly accessible. My copy of the
> >> language
> >> spec is at work...
> >>
> >
> > I'm sure it's feasible to implement access via reflection (which is what
> > Digester uses) to methods defined public through an interface - we ran
> > into a similar case in BeanUtils and solved it be looking up an
> > appropriate java.lang.reflect.Method object correctly.  I'm not sure what
> > happens when you shadow a package-private method with a public one -- will
> > have to check on that.  However, AFAIK, the class itself has to be public
> > for any of this to work.
> hi craig
> this is sort of (tangentially) related to some stuff i was thinking about
> recently. betwixt (without any deep knowledge of the code - hopefully
> james will correct me if i'm wrong) has some code which does some wangling
> for this kind of case.
> at the moment the setNextRule (and other similar rules) uses reflection to
> call methods. it always looks for a method with an exact parameter match
> for the class it's going to pass in. this means that it won't find methods
> with the right name whose signature takes an interface implemented by the
> class or which takes a superclass. this isn't (usually) a big problem
> since the same functionality can be achieved by specifying the class but
> it is something that has confused new users. (i suppose that probably in
> this case, an improved method finder would have made a difference, though.
> )

We use Digester in the HEAD branch of Tomcat 4 to read server.xml and
web.xml files.  There are lots of cases where a public method takes an
interface, while the actual objects involved are specific implementation
instances, and things work fine -- like this (grossly simplified from
reality, but illustrating the point):

    public interface Container {
      public void addChild(Container child);

    public class StandardEngine implements Container {

    public class StandardHost implements Container {

with Digester rules like:

    digester.addObjectCreate("Engine", "StandardEngine");
    digester.addObjectCreate("Engine/Host", "StandardHost");
    digester.addSetNext("Engine/Host", "addChild", "Container");

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

Is this the case you're talking about?

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

> - robert


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

View raw message