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] CallMethodRule bug
Date Thu, 18 Jul 2002 18:07:28 GMT

On Wednesday, July 17, 2002, at 06:37 PM, Martin Cooper wrote:

>
>
>> -----Original Message-----
>> From: robert burrell donkin [mailto:robertdonkin@mac.com]
>> Sent: Wednesday, July 17, 2002 10:35 AM
>> To: Jakarta Commons Developers List
>> Subject: [digester] CallMethodRule bug

<snip>

>> this may subtly break some digestion rulesets (since invokeMethod may
>> under some rare circumstances return a different match from
>> invokeExactMethod) which will have to be fixed by setting
>> flags on some
>> CallMethodRules. we didn't have any complaints from users
>> when we made
>> this change for other rules so i'm pretty confident that the
>> incompatibility doesn't occur often in the wild.
>
> Can you say more on the "rare circumstances"? Would this just be when 
> there
> are multiple overloads that would match inexactly, while only one would
> match exactly?

invokeExactMethod relies on class.getMethod.

invokeMethod relies on going through the public methods from 
class.getMethods.

if there this is more than one method with compatible parameter types then 
in certain circumstances, class.getMethod makes an arbitrary choice 
between them. in these circumstances, invokeMethod also makes an arbitrary 
choice between them. in the rare circumstance that user digestion code 
relies on this arbitrary ordering working in a particular way (and the 
arbitrary ordering used by invokeMethod differs from that used by the 
class.getMethod implementation), then this change will break the user 
ruleset.

(there may be other circumstances where they return different values but 
these are really bugs.)

>> is this a good plan?
>
> Assuming the rare circumstances really are that, then yes, this sounds 
> like
> a good plan to me. Support for primitive types is a good thing!

digester will support primitives one way or another :)

i order to support primitives, i need to do method walking. that means 
that it's neater to modify invokeMethod since this is how it works anyway 
rather than adding a special case to invokeExactMethod

- 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