|
From: Colin S. <col...@ex...> - 2003-11-26 19:36:16
|
In the meantime, I've done a somewhat smarter/dumber solution (depending on your point of view). At afterPropertiesSet time, MethodInvokingFactoryBean will try to match a target method with the exact same name and exact same arg types. If that doesn't work, it will try to find one (and only one) method with the exact same name, and the same number of arguments. In this case, it will potentially match an improper method, but it relies on a runtime failuer (IllegalArgumentException) when getObject is called, if the specified method arguments can not be assigned to the target method arguments, by the invoke call. Colin Sampaleanu wrote: > W/regards to doing proper method matching based on argument types in > MethodInvokingFactoryBean, there are a few different levels it can be > taken to. The current code is pretty dumb, it uses reflection to try > to find a target method with the exact same argument types as the > supplied arguments. This won't even work for calling methods which > take arguments which are superclasses of the specified arguments. What > would be pretty easy to do is to rip out the MethodUtils class from > Apache BeanUtils, which can do proper method matching via a method > called getMatchingAccessibleMethod(). The main downside to this is > that MethodUtils compiles to about 7.5k of bytecode. This could > probably be whittled down to about 5k by stripping out some items, but > still, it would increase the base bean handling code by that amount. > The third level would be to do coercion on the level of List -> Array, > etc. > > I don't think the latter is worth it, but I am wondering about the 2nd... > > > Rod Johnson wrote: > >> This is excellent. We had a question about this on the forums >> recently. It's >> pretty powerful to be able to do arbitrary nesting. >> >> Regards, >> Rod >> >> ----- Original Message ----- From: "jürgen höller [werk3AT]" >> <jue...@we...> >> To: <spr...@li...> >> Sent: Wednesday, November 26, 2003 4:37 PM >> Subject: RE: [Springframework-developer] How hard is is to add >> support for >> list inside of a list, in an XML beanfactory def? >> >> >> This is actually pretty simple: We just need to allow for <list> (and >> <map>) >> as sub-element of <list> in the DTD - the bean factory can already >> handle >> any kind of nested element! I've just patched the DTD accordingly and >> committed it; a corresponding unit test passes (not committed yet due to >> other work). >> >> Juergen >> >> >> -----Original Message----- >> From: spr...@li... >> [mailto:spr...@li...]On Behalf >> Of Colin Sampaleanu >> Sent: Wednesday, November 26, 2003 5:15 PM >> To: spr...@li... >> Subject: [Springframework-developer] How hard is is to add support for >> list inside of a list, in an XML beanfactory def? >> >> >> Right now in a bean factory xml definition, a list can not contain a >> list. Can somebody who is more familiar with the bean wrapping estimate >> how big a deal this would be to add? >> >> The issue comes in using the MethodInvokingFactoryBean to invoke a >> method which takes an array or list as an argument. Right now there is >> no way to do it unfortunately. > |