commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertdon...@mac.com>
Subject Re: Digester yielding IllegalAccessException in CallMethodRule, SetNextRule
Date Wed, 05 Dec 2001 18:03:53 GMT
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.
)

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.

- robert


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message