Menu
▾
▴
Re: [Springframework-developer] Type 3 IoC support
|
From: Rob B. <rob...@ve...> - 2003-11-10 17:16:47
|
j=FCrgen YOU ROCK! I knew you could remove the one constructor limitatio= n. I too think IoC type 2 is the way to go, however if you really need to us= e someone else's stuff and need IoC type 3 having it in Spring is great. Later Rob > = > From: j=FCrgen h=F6ller [werk3AT] <jue...@we...> > Date: 2003/11/10 Mon AM 11:11:45 EST > To: <spr...@li...> > Subject: Re: [Springframework-developer] Type 3 IoC support > = > Due to popular demand ;-), I've just added a constructor detection algo= rithm that replaces the former single-constructor requirement. It works s= imilar to Pico's constructor resolution: It starts with the "greediest" c= onstructor, 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= =2E 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; aut= owire=3D"constructor" will just resolve all remaining arguments. A few sa= nity 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* constr= uctor. 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 (gener= ally, the first one according to the order of Class.getConstructors, whic= h 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 differ= ence weight algorithm will kick in. It will determine a weight for the di= fference between the argument types and the actual arguments, prefering m= ore exact matches - (DataSource,TestBean) in case of DataSource and TestB= ean args, in the above case. > = > BTW, Rob, Pico still advocates the single constructor paradigm. Their i= ntroduction (http://www.picocontainer.org/introduction.html) still states= that Pico components need to have one single constructor, while their FA= Q talk about resolving an appropriate constructor (http://www.picocontain= er.org/faq.html#many-constructors) - so much for documentation consistenc= y. > = > 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 c= onstructor arguments, just like we do with bean properties. Effectively, = bean-style Type 2 IoC vs constructor-style Type 3 IoC is now the applicat= ion developer's choice when using a Spring bean factory. Note that the Pi= co guys have already stated that they will *not* support Type 2 IoC any t= ime 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 yo= u > 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 sup= port > 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 featur= e 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= =2E 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 usef= ul. > = > Spring is already amazing, and you guys just keep making it better. Go= od > work! > = > Later > Rob > > > > > >The only limitation is that constructor-wired components are just al= lowed > to have one single constructor. This is also what Pico recommends, alth= ough > they have some heuristic kind of constructor choice in case of multiple= > constructors now. I guess we can limit this to one single constructor f= or > the time being. Of course, standard beans defined without > autowire=3D"constructor" or "constructor-arg" tags can still have any n= umber > 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 allowin= g > > the deployer to specify, in the case of the indexed variant, an optio= nal > > 'type' attribute which specifies the real type (in the receiving obje= ct) > > 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 suppor= t > > 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-develope= r > = > = > = > ------------------------------------------------------- > 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 > = |
