hi bart you've found the case i had in mind when i was going to write that method :)
i have some more stuff i plan to add to digester (it'll have to wait until i've completed some other stuff i'm working on, though) but now i know that there are users out that need this, i'll try to add that functionality at the same time. (unless there is anyone out there who wants to beat me to it...) - 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]>
