Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2003-11-10 16:14:25
|
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 |
|
From: <jue...@we...> - 2003-11-10 16:36:02
|
Brian,
I still favour the bean style too: Fot example, having to pass 2 =
separate DataSource instances in via constructor argument indizes is a =
nuisance - it's much nicer if you can have "productDataSource" and =
"inventoryDataSource" bean properties. And with simple configuration =
parameters, it is extremely important to have proper naming: a =
(String,String,String) constructor isn't really self-explanatory, but =
"setUsername"/"setPassword"/"setUrl" is.
I consider applying simple configuration parameters as a major =
responsibility of a lightweight container. Like Rod says, the =
alternative would be ad-hoc reading in and parsing of properties files - =
why prefer that to strongly-typed bean properties of type String/int/etc =
that get set by the container? Spring also supports setting values from =
properties files, BTW: You can leverage PropertyPlaceholderConfigurer =
and leave placeholders in your bean definitions, to be resolved as keys =
in a properties file at runtime. In any case, your components don't have =
to care.
An example for handling simple configuration properties in a Spring =
application context:
<!-- framework bean, not to be referenced by application objects -->
<bean id=3D"myConf" =
class=3D"org.springframework.context.config.PropertyPlaceholderConfigurer=
">
<property =
name=3D"location"><value>WEB-INF/my.conf</value></property>
</bean>
<!-- resource bean, to be referenced by data access objects -->
<bean id=3D"dataSource" =
class=3D"org.apache.commons.dbcp.BasicDataSource">
<property =
name=3D"driverClassName"><value>${dbdriver}</value></property>
<property name=3D"url"><value>${dburl}</value></property>
<property name=3D"username"><value>${dbuser}</value></property>
<property name=3D"password"><value>${dbpw}</value></property>
</bean>
The my.conf properties file contains the following entries, targetted at =
system administrators:
dbdriver=3Dcom.mysql.jdbc.Driver
dburl=3Djdbc:mysql://myhost:3306/mydb
dbuser=3Dmyuser
dbpw=3D
Juergen
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Rod Johnson
Sent: Monday, November 10, 2003 9:49 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Type 3 IoC support
Brian,
We have an article on the Spring site about Type 2 and 3 comparison.
With Spring's autowire the configuration volume can be reduced for =
simple
cases (one object per type). Anyway, how dependencies are exposed has
nothing to do with how metadata configuration (if any) is stored. With =
more
complex (and realistic) cases Pico also requires configuration =
information.
I think the constructor style works well for simple objects (a small =
number
of dependencies, no likelihood of subclassing, and no configuration
parameters). However I think the JavaBeans approach scales better to the
complexity of typical application objects.
Anyway, part of the point of the changes is that we don't need to argue =
over
this any more. We will continue to recommend the use of JavaBeans as =
best
practice in most cases, but leave users to decide what they prefer.
I absolutely think the container should be responsible for configuration
properties, rather than just dependencies. In fact this was the first =
itch I
needed to scratch in starting to develop what become the Spring bean
factory. The alternative is likely to be ad hoc config lookups =
everywhere
and untestable code.
Regards,
Rod
----- Original Message -----=20
From: "Brian McCallister" <br...@ap...>
To: <spr...@li...>
Sent: Monday, November 10, 2003 1:21 AM
Subject: Re: [Springframework-developer] Type 3 IoC support
> On Sunday, November 9, 2003, at 05:47 PM, Rod Johnson wrote:
> > I think that although we should continue to advocate JavaBeans =
("Type
> > 2") as
> > the best alternative in most cases, Type 3 is a good choice in a
> > minority of
> > cases. And in any case, the Spring philosophy is to be =
non-intrusive.
> > We
> > don't want to tell people how they should code.
>
> I am curious why you think that Type 2, JavaBean bases, IoC frameworks
> are a better option. I would tend to think that the more obvious
> constructor oriented dependency resolution is easier to work with and
> maintain. One of the things that has bothered me looking at Spring was
> the considerable volume of configuration xml compared to something =
like
> a PicoContainer.
>
> I don't think that the component container should be responsible for
> configuring the various components - only for supplying the
> dependencies and, maybe, lifecycle management. The component =
framework,
> to paraphrase yourself, should stay out of the way and not affect the
> components themselves. I see a a complex set of JavaBean style
> configuration options managed by the framework as a liability as far =
as
> this goes.
>
> -Brian
>
>
>
>
> -------------------------------------------------------
> 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
|
|
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 |
|
From: <jue...@we...> - 2003-11-10 16:46:23
|
Autowiring both constructor arguments and bean properties is a bit = awkward. Either you resolve dependencies of a certain bean via a = constructor or via bean properties - but not both ways, especially if = autowiring. For example, a bean might contain a constructor with a = DataSource argument and a bean property of type DataSource - but doesn't = expect to get passed both, as they are just alternative means of setting = its DataSource. When specifying direct references via "constructor-arg" and "property", = you can of course pass certain dependencies into the constructor and = other ones into bean properties. This way, you won't experience side = effects of double setting etc as in the = autowiring-both-constructors-and-properties case. With direct = references, you should be able to apply any kind of = constructor/properties combination. Finally, as you assume, "constructor-arg" tags will be applied before = autowiring - just like "property" tags. The exact order for resolving a = constructor argument is: Indexed constructor argument value, generic = constructor argument value that matches by type, autowired value (if = activated). Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Alef Arendsen (JTeam) Sent: Sunday, November 09, 2003 11:22 PM To: spr...@li... Subject: RE: [Springframework-developer] Type 3 IoC support Hmm, this looks promising. I don't want to get to deep in the source now, so two basic questions (so I can immediately put this in the docs as well): I was wondering how multiple autowire types are supported. Is it possible to use both constructor autowiring and byType autowiring (in order to get both constructors have arguments as well as beanstyle setters)? Then, I assume any constructor arguments specified by a constructor-arg will not be included in the autowiring process? Alef > -----Oorspronkelijk bericht----- > Van: spr...@li...=20 > [mailto:spr...@li...] > Namens j=FCrgen h=F6ller [werk3AT] > Verzonden: Sunday, November 09, 2003 10:48 PM > Aan: spr...@li... > Onderwerp: [Springframework-developer] Type 3 IoC support >=20 >=20 > Everybody, > =20 > I'm pleased to announce that a Spring bean factory is now=20 > capable of handling Type 3 IoC components! As the most=20 > important feature, I've introduced autowire=3D"constructor" for=20 > autowiring constructor arguments by type, just like=20 > autowire=3D"byType" does for bean properties.=20 > =20 > Furthermore, there is a "constructor-arg" tag within the=20 > "bean" tag now, to pass specific beans or values to=20 > constructor arguments. "constructor-arg" can specify generic=20 > values that get matched by type, or values for a specific=20 > argument via its "index" attribute. This means that we can=20 > handle any kind of constructor, be it with bean references,=20 > simple values, lists, maps, etc. We can also easily handle=20 > multiple constructor arguments of the same type, i.e. 2=20 > DataSource arguments or 2 String values (in contrast to the=20 > current Pico version)! > =20 > The only limitation is that constructor-wired components are=20 > just allowed to have one single constructor. This is also=20 > what Pico recommends, although they have some heuristic kind=20 > of constructor choice in case of multiple constructors now. I=20 > guess we can limit this to one single constructor for the=20 > time being. Of course, standard beans defined without=20 > autowire=3D"constructor" or "constructor-arg" tags can still=20 > have any number of constructors, the only requirement being=20 > that they must provide a no-arg constructor. > =20 > As an example, the XML bean definition from the test case: > =20 > <beans> > =20 > <bean id=3D"rod1"=20 > class=3D"org.springframework.beans.factory.xml.ConstructorDepend > enciesBean"> > <constructor-arg><ref bean=3D"other"/></constructor-arg> > <constructor-arg><ref bean=3D"kerry2"/></constructor-arg> </bean> > =20 > <bean id=3D"rod2"=20 > class=3D"org.springframework.beans.factory.xml.ConstructorDepend > enciesBean"> > <constructor-arg index=3D"1"><ref = bean=3D"kerry1"/></constructor-arg> > <constructor-arg index=3D"0"><ref = bean=3D"kerry2"/></constructor-arg> > <constructor-arg><ref bean=3D"other"/></constructor-arg> </bean> > =20 > <bean id=3D"rod3"=20 > class=3D"org.springframework.beans.factory.xml.ConstructorDepend > enciesBean" > autowire=3D"constructor"> > <constructor-arg><ref bean=3D"kerry2"/></constructor-arg> </bean> > =20 > <bean id=3D"rod4"=20 > class=3D"org.springframework.beans.factory.xml.DerivedConstructo > rDependenciesBean"> > <constructor-arg index=3D"1"><ref = bean=3D"kerry1"/></constructor-arg> > <constructor-arg index=3D"3"><value>99</value></constructor-arg> > <constructor-arg><ref bean=3D"other"/></constructor-arg> > <constructor-arg index=3D"4"><value>myname</value></constructor-arg> > <constructor-arg index=3D"0"><ref=20 > bean=3D"kerry2"/></constructor-arg> </bean> > =20 > <bean id=3D"kerry1" class=3D"org.springframework.beans.TestBean"> > <property name=3D"name"> > <value>Kerry</value> > </property> > </bean> > =20 > <bean id=3D"kerry2" class=3D"org.springframework.beans.TestBean"> > <property name=3D"name"> > <value>Kerry</value> > </property> > </bean> > =20 > <bean id=3D"other"=20 > class=3D"org.springframework.beans.factory.LifecycleBean"/> > =20 > </beans> >=20 > Juergen >=20 >=20 > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest=20 > developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV,=20 > and more! http://www.apachecon.com/=20 > _______________________________________________ > Springframework-developer mailing list=20 > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 ------------------------------------------------------- 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 |
|
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 > = |
|
From: Rod J. <rod...@in...> - 2003-11-10 17:28:35
|
>jürgen YOU ROCK! I knew you could remove the one constructor limitation. He is pretty amazing isn't he :-) The most extraordinary thing is not that he does as much as he does (although that is remarkable enough), but that the quality of his work is so consistently high. Regards, Rod |
|
From: <jue...@we...> - 2003-11-10 17:45:37
|
Brian,
I've just changed the XmlBeanFactory id resolution to allow for "bean" =
tags with neither "id" nor "name", using the bean class as implicit id =
(PicoContainer-style). Spring's configuration XML can generally be =
adjusted to just the level that is needed, even more now that you don't =
need to specify ids for autowired components. Let's consider a few =
examples.
In the autowiring case, with automatic resolution of bean properties =
that express dependencies for other components, like a =
"setProductService(ProductService)" method in MyOrderService:
<beans default-autowire=3D"byType">
<bean class=3D"product.MyProductService"/>
<bean class=3D"order.MyOrderService"/>
</beans>
In the autowiring case, with automatic resolution of constructor =
arguments that express dependencies for other components, like a =
"MyOrderService(ProductService)" constructor in MyOrderService:
<beans default-autowire=3D"constructor">
<bean class=3D"product.MyProductService"/>
<bean class=3D"order.MyOrderService"/>
</beans>
In both cases, the MyOrderService instance can be retrieved via =
getBean("order.MyOrderService").
With explicit references via bean properties instead of autowiring:
<beans>
<bean id=3D"myProductService" class=3D"product.MyProductService"/>
<bean id=3D"myOrderService class=3D"order.MyOrderService">
<property name=3D"productService"><ref =
bean=3D"myProductService"/></property>
</bean>
</beans>
With explicit references via constructor arguments instead of =
autowiring:
<beans>
<bean id=3D"myProductService" class=3D"product.MyProductService"/>
<bean id=3D"myOrderService class=3D"order.MyOrderService">
<constructor-arg><ref =
bean=3D"myProductService"/></constructor-arg>
</bean>
</beans>
Here, the MyOrderService instance can be retrieved via =
getBean("myOrderService").
It's hard to imagine an XML-based NanoContainer with PicoContainer =
underneath that beats that level of conciseness. DefaultPicoContainer =
has programmatic registration of components; you can have that with =
Spring's ListableBeanFactoryImpl too. It's hard to see why you would =
prefer programmatic registration to concise XML in any considerably =
large application, though.
Essentially, both a PicoContainer and a Spring bean factory need =
configuration metadata, even exactly the same level depending on your =
configuration needs: component classes, component ids, specific =
parameters. No matter how hard the Pico guys claim "no configuration =
metadata" - this depends on your needs, and Pico and Spring have =
comparable volumes of metadata in that respect.
Juergen
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Brian McCallister
Sent: Monday, November 10, 2003 2:22 AM
To: spr...@li...
Subject: [[W3-SPAM]] - Re: [Springframework-developer] Type 3 IoC
support - Email found in subject
On Sunday, November 9, 2003, at 05:47 PM, Rod Johnson wrote:
> I think that although we should continue to advocate JavaBeans ("Type=20
> 2") as
> the best alternative in most cases, Type 3 is a good choice in a=20
> minority of
> cases. And in any case, the Spring philosophy is to be non-intrusive.=20
> We
> don't want to tell people how they should code.
I am curious why you think that Type 2, JavaBean bases, IoC frameworks=20
are a better option. I would tend to think that the more obvious=20
constructor oriented dependency resolution is easier to work with and=20
maintain. One of the things that has bothered me looking at Spring was=20
the considerable volume of configuration xml compared to something like=20
a PicoContainer.
I don't think that the component container should be responsible for=20
configuring the various components - only for supplying the=20
dependencies and, maybe, lifecycle management. The component framework,=20
to paraphrase yourself, should stay out of the way and not affect the=20
components themselves. I see a a complex set of JavaBean style=20
configuration options managed by the framework as a liability as far as=20
this goes.
-Brian
-------------------------------------------------------
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
|
|
From: <jue...@we...> - 2003-11-10 17:48:48
|
As a side note, you cannot combine autowire "byName" and "byType" = either, although that would technically be possible - both just resolve = what they are able to and ignore the rest. It just doesn't make sense to = mix those autowiring styles, as it can lead to quite unpredictable = behavior. If you've got special requirements, explicit references are = the better choice - you can activate a certain autowiring style by = default and just override specific properties, for example. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of j=FCrgen h=F6ller [werk3AT] Sent: Monday, November 10, 2003 5:44 PM To: spr...@li... Subject: RE: [Springframework-developer] Type 3 IoC support Autowiring both constructor arguments and bean properties is a bit = awkward. Either you resolve dependencies of a certain bean via a = constructor or via bean properties - but not both ways, especially if = autowiring. For example, a bean might contain a constructor with a = DataSource argument and a bean property of type DataSource - but doesn't = expect to get passed both, as they are just alternative means of setting = its DataSource. When specifying direct references via "constructor-arg" and "property", = you can of course pass certain dependencies into the constructor and = other ones into bean properties. This way, you won't experience side = effects of double setting etc as in the = autowiring-both-constructors-and-properties case. With direct = references, you should be able to apply any kind of = constructor/properties combination. Finally, as you assume, "constructor-arg" tags will be applied before = autowiring - just like "property" tags. The exact order for resolving a = constructor argument is: Indexed constructor argument value, generic = constructor argument value that matches by type, autowired value (if = activated). Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Alef Arendsen (JTeam) Sent: Sunday, November 09, 2003 11:22 PM To: spr...@li... Subject: RE: [Springframework-developer] Type 3 IoC support Hmm, this looks promising. I don't want to get to deep in the source now, so two basic questions (so I can immediately put this in the docs as well): I was wondering how multiple autowire types are supported. Is it possible to use both constructor autowiring and byType autowiring (in order to get both constructors have arguments as well as beanstyle setters)? Then, I assume any constructor arguments specified by a constructor-arg will not be included in the autowiring process? Alef > -----Oorspronkelijk bericht----- > Van: spr...@li...=20 > [mailto:spr...@li...] > Namens j=FCrgen h=F6ller [werk3AT] > Verzonden: Sunday, November 09, 2003 10:48 PM > Aan: spr...@li... > Onderwerp: [Springframework-developer] Type 3 IoC support >=20 >=20 > Everybody, > =20 > I'm pleased to announce that a Spring bean factory is now=20 > capable of handling Type 3 IoC components! As the most=20 > important feature, I've introduced autowire=3D"constructor" for=20 > autowiring constructor arguments by type, just like=20 > autowire=3D"byType" does for bean properties.=20 > =20 > Furthermore, there is a "constructor-arg" tag within the=20 > "bean" tag now, to pass specific beans or values to=20 > constructor arguments. "constructor-arg" can specify generic=20 > values that get matched by type, or values for a specific=20 > argument via its "index" attribute. This means that we can=20 > handle any kind of constructor, be it with bean references,=20 > simple values, lists, maps, etc. We can also easily handle=20 > multiple constructor arguments of the same type, i.e. 2=20 > DataSource arguments or 2 String values (in contrast to the=20 > current Pico version)! > =20 > The only limitation is that constructor-wired components are=20 > just allowed to have one single constructor. This is also=20 > what Pico recommends, although they have some heuristic kind=20 > of constructor choice in case of multiple constructors now. I=20 > guess we can limit this to one single constructor for the=20 > time being. Of course, standard beans defined without=20 > autowire=3D"constructor" or "constructor-arg" tags can still=20 > have any number of constructors, the only requirement being=20 > that they must provide a no-arg constructor. > =20 > As an example, the XML bean definition from the test case: > =20 > <beans> > =20 > <bean id=3D"rod1"=20 > class=3D"org.springframework.beans.factory.xml.ConstructorDepend > enciesBean"> > <constructor-arg><ref bean=3D"other"/></constructor-arg> > <constructor-arg><ref bean=3D"kerry2"/></constructor-arg> </bean> > =20 > <bean id=3D"rod2"=20 > class=3D"org.springframework.beans.factory.xml.ConstructorDepend > enciesBean"> > <constructor-arg index=3D"1"><ref = bean=3D"kerry1"/></constructor-arg> > <constructor-arg index=3D"0"><ref = bean=3D"kerry2"/></constructor-arg> > <constructor-arg><ref bean=3D"other"/></constructor-arg> </bean> > =20 > <bean id=3D"rod3"=20 > class=3D"org.springframework.beans.factory.xml.ConstructorDepend > enciesBean" > autowire=3D"constructor"> > <constructor-arg><ref bean=3D"kerry2"/></constructor-arg> </bean> > =20 > <bean id=3D"rod4"=20 > class=3D"org.springframework.beans.factory.xml.DerivedConstructo > rDependenciesBean"> > <constructor-arg index=3D"1"><ref = bean=3D"kerry1"/></constructor-arg> > <constructor-arg index=3D"3"><value>99</value></constructor-arg> > <constructor-arg><ref bean=3D"other"/></constructor-arg> > <constructor-arg index=3D"4"><value>myname</value></constructor-arg> > <constructor-arg index=3D"0"><ref=20 > bean=3D"kerry2"/></constructor-arg> </bean> > =20 > <bean id=3D"kerry1" class=3D"org.springframework.beans.TestBean"> > <property name=3D"name"> > <value>Kerry</value> > </property> > </bean> > =20 > <bean id=3D"kerry2" class=3D"org.springframework.beans.TestBean"> > <property name=3D"name"> > <value>Kerry</value> > </property> > </bean> > =20 > <bean id=3D"other"=20 > class=3D"org.springframework.beans.factory.LifecycleBean"/> > =20 > </beans> >=20 > Juergen >=20 >=20 > ------------------------------------------------------- > This SF.Net email sponsored by: ApacheCon 2003, > 16-19 November in Las Vegas. Learn firsthand the latest=20 > developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV,=20 > and more! http://www.apachecon.com/=20 > _______________________________________________ > Springframework-developer mailing list=20 > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer >=20 ------------------------------------------------------- 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 |
|
From: <jue...@we...> - 2003-11-10 17:55:47
|
*blush* ehm, thanks, ehm... *blush* I guess I need to throw in a bunch of crap code once in a while, just to = convince people that there's a human at work ;-) Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Rod Johnson Sent: Monday, November 10, 2003 6:25 PM To: spr...@li... Subject: Re: [Springframework-developer] Type 3 IoC support >j=FCrgen YOU ROCK! I knew you could remove the one constructor = limitation. He is pretty amazing isn't he :-) The most extraordinary thing is not that he does as much as he does (although that is remarkable enough), but that the quality of his work = is so consistently high. Regards, Rod ------------------------------------------------------- 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 |
|
From: <jue...@we...> - 2003-11-15 12:45:34
|
Colin,
=20
The problem is that you tried to pass a <list> into a String[] =
constructor. The generic constructor argument matcher did not recognize =
that as compatible, therefore it continued with the next constructor. If =
you explicitly specified an index, the matching was not by type and =
therefore worked.
=20
I've just added a check to match an array argument with a List value, =
and also a unit test that instantiates a parent and child =
ClassPathXmlApplicationContext (without explicit indexes specified).
=20
The exception "2 constructor arguments specified but just constructor =
with 1 argument found" was a bit misleading, as it rather indicates "no =
matching constructor found" (with at least the given number of =
arguments). I've already changed its wording.
=20
So please grab the latest CVS snapshot and happily instantiate =
ClassPathXmlApplicationContexts for whatever reason :-)
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von Colin Sampaleanu
Gesendet: Fr 14.11.2003 23:55
An: spr...@li...
Betreff: Re: [Springframework-developer] Type 3 IoC support
There is definitely an issue. When trying to use the two argument
constructor, of which there is only one, I get
; nested exception is:
org.springframework.beans.factory.BeanDefinitionStoreException: 2
constructor arguments specified but just constructor with 1 arguments
found in bean 'packaging-context'
org.springframework.beans.factory.BeanDefinitionStoreException: 2
constructor arguments specified but just constructor with 1 arguments
found in bean 'packaging-context'
at
org.springframework.beans.factory.support.AbstractBeanFactory.autowireCon=
structor(AbstractBeanFactory.java:444)
at
org.springframework.beans.factory.support.AbstractBeanFactory.createBean(=
AbstractBeanFactory.java:352)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getSharedIn=
stance(AbstractBeanFactory.java:274)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abs=
tractBeanFactory.java:203)
at
org.springframework.beans.factory.support.AbstractBeanFactory.resolveRefe=
rence(AbstractBeanFactory.java:717)
at
org.springframework.beans.factory.support.AbstractBeanFactory.resolveValu=
eIfNecessary(AbstractBeanFactory.java:688)
at
org.springframework.beans.factory.support.AbstractBeanFactory.autowireCon=
structor(AbstractBeanFactory.java:418)
at
org.springframework.beans.factory.support.AbstractBeanFactory.createBean(=
AbstractBeanFactory.java:352)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getSharedIn=
stance(AbstractBeanFactory.java:274)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abs=
tractBeanFactory.java:203)
at
org.springframework.beans.factory.support.AbstractBeanFactory.resolveRefe=
rence(AbstractBeanFactory.java:717)
at
org.springframework.beans.factory.support.AbstractBeanFactory.resolveValu=
eIfNecessary(AbstractBeanFactory.java:688)
at
org.springframework.beans.factory.support.AbstractBeanFactory.autowireCon=
structor(AbstractBeanFactory.java:418)
at
org.springframework.beans.factory.support.AbstractBeanFactory.createBean(=
AbstractBeanFactory.java:352)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getSharedIn=
stance(AbstractBeanFactory.java:274)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(Abs=
tractBeanFactory.java:203)
at
org.springframework.context.support.AbstractApplicationContext.getBean(Ab=
stractApplicationContext.java:468)
at
org.springframework.context.support.AbstractApplicationContext.preInstant=
iateSingletons(AbstractApplicationContext.java:354)
at
org.springframework.context.support.AbstractApplicationContext.refresh(Ab=
stractApplicationContext.java:240)
However, if I add index=3D"0" and index=3D"1" respectively, to the two
constructor arguments, then it has no problem constructing it. Now my
understanding is that the indexes shouldn't be necessary in this
(non-ambiguous) case.
Again, I'll probably be able to look at this on Mon. or Tues. if nobody
else has by then.
Regards,
Colin
Colin Sampaleanu wrote:
> Juergen,
>
> I think the constructor resolution may not be quite right. The
> following bean entry fails:
> <bean id=3D"data-access-context"
> =20
> =
class=3D"org.springframework.context.support.ClassPathXmlApplicationConte=
xt">
>
> <constructor-arg>
> <list><value>/data-access-applicationContext.xml</value></list>
> </constructor-arg>
> </bean>
> with
> ...
> =20
> org.springframework.beans.factory.UnsatisfiedDependencyException: Bean =
w
> ith name 'data-access-context' has an unsatisfied dependency expressed
> through c
> onstructor argument with index 0 of type [java.lang.String]
>
> Where it should be able to resolve to the constructor which takes an
> array of Strings. Now I will probably look into this myself later, but
> wanted to give you a heads up in case you know offhand what the
> problem is. For the time being, I am in a hurry, and will just feed
> the one string I need to the constructor which takes one string.
>
> As to why I am trying to construct a context inside a context, I am
> doing some interesting coding; we can get into that later when
> everything is working :-)
|
|
From: Colin S. <col...@ex...> - 2003-11-15 13:48:03
|
Thanks Juergen. I actually did not have time to look at the Spring code yesterday, but just assumed the List to String[] match would work, since the DTD (explicitly) said a List to array conversion would be done automatically. Of course, conversion once matched, and the matching itself (in the new code) are not quie the same thing :-) I'll give the code a try later... jürgen höller [werk3AT] wrote: >Colin, > >The problem is that you tried to pass a <list> into a String[] constructor. The generic constructor argument matcher did not recognize that as compatible, therefore it continued with the next constructor. If you explicitly specified an index, the matching was not by type and therefore worked. > >I've just added a check to match an array argument with a List value, and also a unit test that instantiates a parent and child ClassPathXmlApplicationContext (without explicit indexes specified). > >The exception "2 constructor arguments specified but just constructor with 1 argument found" was a bit misleading, as it rather indicates "no matching constructor found" (with at least the given number of arguments). I've already changed its wording. > >So please grab the latest CVS snapshot and happily instantiate ClassPathXmlApplicationContexts for whatever reason :-) > >Juergen > > >________________________________ > >Von: spr...@li... im Auftrag von Colin Sampaleanu >Gesendet: Fr 14.11.2003 23:55 >An: spr...@li... >Betreff: Re: [Springframework-developer] Type 3 IoC support > > > >There is definitely an issue. When trying to use the two argument >constructor, of which there is only one, I get > >; nested exception is: > org.springframework.beans.factory.BeanDefinitionStoreException: 2 >constructor arguments specified but just constructor with 1 arguments >found in bean 'packaging-context' >org.springframework.beans.factory.BeanDefinitionStoreException: 2 >constructor arguments specified but just constructor with 1 arguments >found in bean 'packaging-context' > at >org.springframework.beans.factory.support.AbstractBeanFactory.autowireConstructor(AbstractBeanFactory.java:444) > at >org.springframework.beans.factory.support.AbstractBeanFactory.createBean(AbstractBeanFactory.java:352) > at >org.springframework.beans.factory.support.AbstractBeanFactory.getSharedInstance(AbstractBeanFactory.java:274) > at >org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:203) > at >org.springframework.beans.factory.support.AbstractBeanFactory.resolveReference(AbstractBeanFactory.java:717) > at >org.springframework.beans.factory.support.AbstractBeanFactory.resolveValueIfNecessary(AbstractBeanFactory.java:688) > at >org.springframework.beans.factory.support.AbstractBeanFactory.autowireConstructor(AbstractBeanFactory.java:418) > at >org.springframework.beans.factory.support.AbstractBeanFactory.createBean(AbstractBeanFactory.java:352) > at >org.springframework.beans.factory.support.AbstractBeanFactory.getSharedInstance(AbstractBeanFactory.java:274) > at >org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:203) > at >org.springframework.beans.factory.support.AbstractBeanFactory.resolveReference(AbstractBeanFactory.java:717) > at >org.springframework.beans.factory.support.AbstractBeanFactory.resolveValueIfNecessary(AbstractBeanFactory.java:688) > at >org.springframework.beans.factory.support.AbstractBeanFactory.autowireConstructor(AbstractBeanFactory.java:418) > at >org.springframework.beans.factory.support.AbstractBeanFactory.createBean(AbstractBeanFactory.java:352) > at >org.springframework.beans.factory.support.AbstractBeanFactory.getSharedInstance(AbstractBeanFactory.java:274) > at >org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:203) > at >org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:468) > at >org.springframework.context.support.AbstractApplicationContext.preInstantiateSingletons(AbstractApplicationContext.java:354) > at >org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:240) > >However, if I add index="0" and index="1" respectively, to the two >constructor arguments, then it has no problem constructing it. Now my >understanding is that the indexes shouldn't be necessary in this >(non-ambiguous) case. > >Again, I'll probably be able to look at this on Mon. or Tues. if nobody >else has by then. > >Regards, >Colin > > >Colin Sampaleanu wrote: > > > >>Juergen, >> >>I think the constructor resolution may not be quite right. The >>following bean entry fails: >> <bean id="data-access-context" >> >>class="org.springframework.context.support.ClassPathXmlApplicationContext"> >> >> <constructor-arg> >> <list><value>/data-access-applicationContext.xml</value></list> >> </constructor-arg> >> </bean> >>with >> ... >> >>org.springframework.beans.factory.UnsatisfiedDependencyException: Bean w >>ith name 'data-access-context' has an unsatisfied dependency expressed >>through c >>onstructor argument with index 0 of type [java.lang.String] >> >>Where it should be able to resolve to the constructor which takes an >>array of Strings. Now I will probably look into this myself later, but >>wanted to give you a heads up in case you know offhand what the >>problem is. For the time being, I am in a hurry, and will just feed >>the one string I need to the constructor which takes one string. >> >>As to why I am trying to construct a context inside a context, I am >>doing some interesting coding; we can get into that later when >>everything is working :-) >> >> |
|
From: Rod J. <rod...@in...> - 2003-11-10 16:24:08
|
>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 ----- From: "jürgen höller [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="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="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 |
|
From: Colin S. <col...@ex...> - 2003-11-14 21:41:47
|
Juergen,
I think the constructor resolution may not be quite right. The following
bean entry fails:
<bean id="data-access-context"
class="org.springframework.context.support.ClassPathXmlApplicationContext">
<constructor-arg>
<list><value>/data-access-applicationContext.xml</value></list>
</constructor-arg>
</bean>
with
...
org.springframework.beans.factory.UnsatisfiedDependencyException: Bean w
ith name 'data-access-context' has an unsatisfied dependency expressed
through c
onstructor argument with index 0 of type [java.lang.String]
Where it should be able to resolve to the constructor which takes an
array of Strings. Now I will probably look into this myself later, but
wanted to give you a heads up in case you know offhand what the problem
is. For the time being, I am in a hurry, and will just feed the one
string I need to the constructor which takes one string.
As to why I am trying to construct a context inside a context, I am
doing some interesting coding; we can get into that later when
everything is working :-)
jürgen höller [werk3AT] wrote:
>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="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="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
>>
>>
|
|
From: Rod J. <rod...@in...> - 2003-11-14 21:48:52
|
> As to why I am trying to construct a context inside a context, I am > doing some interesting coding; we can get into that later when > everything is working :-) Sounds very interesting indeed. Regards, Rod |
|
From: Colin S. <col...@ex...> - 2003-11-14 22:55:27
|
There is definitely an issue. When trying to use the two argument
constructor, of which there is only one, I get
; nested exception is:
org.springframework.beans.factory.BeanDefinitionStoreException: 2
constructor arguments specified but just constructor with 1 arguments
found in bean 'packaging-context'
org.springframework.beans.factory.BeanDefinitionStoreException: 2
constructor arguments specified but just constructor with 1 arguments
found in bean 'packaging-context'
at
org.springframework.beans.factory.support.AbstractBeanFactory.autowireConstructor(AbstractBeanFactory.java:444)
at
org.springframework.beans.factory.support.AbstractBeanFactory.createBean(AbstractBeanFactory.java:352)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getSharedInstance(AbstractBeanFactory.java:274)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:203)
at
org.springframework.beans.factory.support.AbstractBeanFactory.resolveReference(AbstractBeanFactory.java:717)
at
org.springframework.beans.factory.support.AbstractBeanFactory.resolveValueIfNecessary(AbstractBeanFactory.java:688)
at
org.springframework.beans.factory.support.AbstractBeanFactory.autowireConstructor(AbstractBeanFactory.java:418)
at
org.springframework.beans.factory.support.AbstractBeanFactory.createBean(AbstractBeanFactory.java:352)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getSharedInstance(AbstractBeanFactory.java:274)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:203)
at
org.springframework.beans.factory.support.AbstractBeanFactory.resolveReference(AbstractBeanFactory.java:717)
at
org.springframework.beans.factory.support.AbstractBeanFactory.resolveValueIfNecessary(AbstractBeanFactory.java:688)
at
org.springframework.beans.factory.support.AbstractBeanFactory.autowireConstructor(AbstractBeanFactory.java:418)
at
org.springframework.beans.factory.support.AbstractBeanFactory.createBean(AbstractBeanFactory.java:352)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getSharedInstance(AbstractBeanFactory.java:274)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:203)
at
org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:468)
at
org.springframework.context.support.AbstractApplicationContext.preInstantiateSingletons(AbstractApplicationContext.java:354)
at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:240)
However, if I add index="0" and index="1" respectively, to the two
constructor arguments, then it has no problem constructing it. Now my
understanding is that the indexes shouldn't be necessary in this
(non-ambiguous) case.
Again, I'll probably be able to look at this on Mon. or Tues. if nobody
else has by then.
Regards,
Colin
Colin Sampaleanu wrote:
> Juergen,
>
> I think the constructor resolution may not be quite right. The
> following bean entry fails:
> <bean id="data-access-context"
>
> class="org.springframework.context.support.ClassPathXmlApplicationContext">
>
> <constructor-arg>
> <list><value>/data-access-applicationContext.xml</value></list>
> </constructor-arg>
> </bean>
> with
> ...
>
> org.springframework.beans.factory.UnsatisfiedDependencyException: Bean w
> ith name 'data-access-context' has an unsatisfied dependency expressed
> through c
> onstructor argument with index 0 of type [java.lang.String]
>
> Where it should be able to resolve to the constructor which takes an
> array of Strings. Now I will probably look into this myself later, but
> wanted to give you a heads up in case you know offhand what the
> problem is. For the time being, I am in a hurry, and will just feed
> the one string I need to the constructor which takes one string.
>
> As to why I am trying to construct a context inside a context, I am
> doing some interesting coding; we can get into that later when
> everything is working :-)
>
>
>
>
> jürgen höller [werk3AT] wrote:
>
>> 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="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="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
>>>
>>
|
