Cool! I'll check it out and see if I can cut some from the Digester rules setup!
Thanks very much, BG ----- Original Message ----- From: "robert burrell donkin" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Cc: "Bart Guijt" <[EMAIL PROTECTED]> Sent: Wednesday, March 20, 2002 11:49 PM Subject: (Digester) More flexible mothod matching [Was Re: [BeanUtils] invokeExactMethod() --> invokeMethod() ?] > i've now committed changes to SetNextRule, SetRootRule and SetTopRule that > allow the user to choose whether to use the more flexible method matching > MethodUtils.invokeMethod or the original, more precise > MethodUtils.invokeExactMethod. i've made the more flexible behaviour the > default since i think that it's more intuitive. this choice may break a > very small amount of existing code but this can be fixed by enabling exact > matches for that rule. > > hopefully, these changes do pretty much want Bart wanted. > > - robert > > > On Tuesday, February 12, 2002, at 11:22 PM, Bart Guijt wrote: > > > From: "robert burrell donkin" <[EMAIL PROTECTED]> > >> On Monday, February 11, 2002, at 09:29 PM, Bart Guijt wrote: > >>> Right now we need to use this particular feature using the commons > >>> Digester. > >> > >> do you have a concrete example? i might be able to suggest how you could > >> achieve what you want without requiring this change. > > > > After reviewing and tweaking our digester rules setup code, we were able > > to > > use umodified digester/beanutils packages. So after all, the BeanUtils > > changes seem to be unnecessary. > > > > The problem was creating digester rules for XML like this: > > > > <a> > > <b> > > <b> > > <b /> > > <b /> > > </b> > > <b /> > > </b> > > </a> > > > > Here you see a tree of 'b' elements inside of 'a'. We want to translate > > this > > into an objecttree where each element contains a list of its children. The > > Digester provides the 'addSetNextRule' method to achieve this. > > > > If you have a rule matching each '*/b' element you can only specify one > > class as the parent type (either for 'a' or 'b'). We first tried to have > > both 'a' and 'b' classes implement the same interface. This didn't work, > > the > > beanutils package threw InvokationTargetExceptions (or something like > > that). > > We then tried to create two setNextRules, one matching the 'a/b' element > > and > > another matching the '*/b' elements, using two separate parent types far > > 'a' > > and 'b'. This solved the problem. > > > >>> 2. I already took a leap to implement a method > >>> 'getMatchingPublicMethod(Class clazz, String methodName, Class[] > >>> paramTypes)' which returns the correct method and is called from the > >>> 'getAccessibleMethodFromInterfaceNest()' method. This seems to work, aka > >>> the tests don't fail. Since this change defuses the > > 'invoke*Exact*Method( > >>> )' semantics, is this the right solution? It seems either the methods > >>> need to be renamed or the Digester code needs to be adjusted to call a > >>> new 'invokeMethod()'. > >> > >> i'm a bit confused by this paragraph. if you're proposing a patch then i' > >> d > >> find your logic easier to follow if you could supply a cvs diff -u. > > > > Re-reading this paragraph confuses me as well :-) > > > > Anyway, thanks for your attention! > > > >> - robert > > > > Bart Guijt > > > > > > > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]. > > org> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]. > > org> > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
