Menu
▾
▴
RE: [Springframework-developer] Type 3 IoC support
|
From: <jue...@we...> - 2003-11-10 16:36:40
|
You meant to persuade him to support Type 2, of course ;-) Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Rod Johnson Sent: Monday, November 10, 2003 5:22 PM To: spr...@li... Subject: Re: [Springframework-developer] Type 3 IoC support >Note that the Pico guys have already stated that they will *not* = support Type 2 IoC any time soon but just their flavour of Type 3. A couple of weeks ago, I tried to persuade Paul to support Type 3, but = to no avail. Btw, Paul and I got on great: we agree on a lot of stuff, such as the importance of IoC, TDD, lightweight architectures etc. Regards, Rod ----- Original Message -----=20 From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...> To: <spr...@li...> Sent: Monday, November 10, 2003 4:11 PM Subject: Re: [Springframework-developer] Type 3 IoC support Due to popular demand ;-), I've just added a constructor detection = algorithm that replaces the former single-constructor requirement. It works = similar to Pico's constructor resolution: It starts with the "greediest" = constructor, i.e. the one with the most arguments, and then falls back to the next = one in the greediness order if it can't resolve all dependencies. If there are multiple constructors with the same number of arguments, all of them are tried; the first one that can be satisfied will be used. Of course, all "constructor-arg" hints will be applied in any case; autowire=3D"constructor" will just resolve all remaining arguments. A = few sanity checks are performed, like only resolving a constructor that has = at least as many arguments as there are "constructor-arg" tags. This should be sufficiently powerful to be able to address *any* constructor. For example, if there are constructors = (DataSource,TestBean) and (TestBean,DataSource), autowiring or generic "constructor-arg" tags = with a DataSource and a TestBean will use an undetermined one of the two (generally, the first one according to the order of = Class.getConstructors, which can vary from JVM to JVM). If you need a specific one, use "constructor-arg" with corresponding "index" attributes. If multiple constructors with the same number and position of arguments match, like (DataSource,TestBean) and (DataSource,Object), a type = difference weight algorithm will kick in. It will determine a weight for the = difference between the argument types and the actual arguments, prefering more = exact matches - (DataSource,TestBean) in case of DataSource and TestBean args, = in the above case. BTW, Rob, Pico still advocates the single constructor paradigm. Their introduction (http://www.picocontainer.org/introduction.html) still = states that Pico components need to have one single constructor, while their = FAQ talk about resolving an appropriate constructor (http://www.picocontainer.org/faq.html#many-constructors) - so much for documentation consistency. I consider our Type 3 IoC support now more capable than Pico's: We also support arrays, lists, and maps of components or parameters going into constructor arguments, just like we do with bean properties. = Effectively, bean-style Type 2 IoC vs constructor-style Type 3 IoC is now the = application developer's choice when using a Spring bean factory. Note that the Pico = guys have already stated that they will *not* support Type 2 IoC any time = soon but just their flavour of Type 3. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Rob Butler Sent: Sunday, November 09, 2003 11:47 PM To: spr...@li... Subject: [[W3-SPAM]] - Re: [Springframework-developer] Type 3 IoC support - Email found in subject I would agree this is very good stuff! This is especially useful if you want to use a third party api but they do not conform to javabean style no-arg contructors. However by limiting the implementation to only = support classes that have a single constructor you are all but defeating its usefulness. The only reason you would be forced to use / need this kind of a feature = is if you don't have access to the code to implement a no-arg constructor. = For that same reason, you cannot modify the code to only have 1 constructor. = I would wager that most classes that do provide a constructor which takes = args also supply variations that take more / less args. So if multiple constructors are not supported, it's probably not going to be very = useful. Spring is already amazing, and you guys just keep making it better. = Good work! Later Rob > > > >The only limitation is that constructor-wired components are just = allowed to have one single constructor. This is also what Pico recommends, = although they have some heuristic kind of constructor choice in case of multiple constructors now. I guess we can limit this to one single constructor = for the time being. Of course, standard beans defined without autowire=3D"constructor" or "constructor-arg" tags can still have any = number of constructors, the only requirement being that they must provide a = no-arg constructor. > > > > > One way you could do it (which you probably thought of) is by allowing > the deployer to specify, in the case of the indexed variant, an = optional > 'type' attribute which specifies the real type (in the receiving = object) > of that constructor argument. This would allow the appropriate > constructor to be picked without any ambiguity. I don't know if this = is > worth doing or not, but on the other hand, if you are going to support > constructors at all, it's somewhat arbitrary to stop at 1 if you can > figure out a relatively simple (albeit wordy) way to support the > multiple case. > > Even if that is not done, maybe it is worth it supporting the special > case of classes which have a no-arg constructor, and one other > constructor with one or more args. That's also a pretty common case, = and > easy to support. > > Regards, > Colin > > > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest > developments in Apache, PHP, Perl, XML, Java, MySQL, > WebDAV, and more! http://www.apachecon.com/ > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
