Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2003-11-09 21:50:15
|
Everybody, =20 I'm pleased to announce that a Spring bean factory is now capable of = handling Type 3 IoC components! As the most important feature, I've = introduced autowire=3D"constructor" for autowiring constructor arguments = by type, just like autowire=3D"byType" does for bean properties.=20 =20 Furthermore, there is a "constructor-arg" tag within the "bean" tag now, = to pass specific beans or values to constructor arguments. = "constructor-arg" can specify generic values that get matched by type, = or values for a specific argument via its "index" attribute. This means = that we can handle any kind of constructor, be it with bean references, = simple values, lists, maps, etc. We can also easily handle multiple = constructor arguments of the same type, i.e. 2 DataSource arguments or 2 = String values (in contrast to the current Pico version)! =20 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. =20 As an example, the XML bean definition from the test case: =20 <beans> =20 <bean id=3D"rod1" = class=3D"org.springframework.beans.factory.xml.ConstructorDependenciesBea= n"> <constructor-arg><ref bean=3D"other"/></constructor-arg> <constructor-arg><ref bean=3D"kerry2"/></constructor-arg> </bean> =20 <bean id=3D"rod2" = class=3D"org.springframework.beans.factory.xml.ConstructorDependenciesBea= n"> <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" = class=3D"org.springframework.beans.factory.xml.ConstructorDependenciesBea= n" autowire=3D"constructor"> <constructor-arg><ref bean=3D"kerry2"/></constructor-arg> </bean> =20 <bean id=3D"rod4" = class=3D"org.springframework.beans.factory.xml.DerivedConstructorDependen= ciesBean"> <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 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" = class=3D"org.springframework.beans.factory.LifecycleBean"/> =20 </beans> Juergen |
|
From: Alef A. \(JTeam\) <al...@jt...> - 2003-11-09 22:22:54
|
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 |
|
From: Colin S. <col...@ex...> - 2003-11-09 22:28:24
|
jürgen höller [werk3AT] wrote: >Everybody, > >I'm pleased to announce that a Spring bean factory is now capable of handling Type 3 IoC components! As the most important feature, I've introduced autowire="constructor" for autowiring constructor arguments by type, just like autowire="byType" does for bean properties. > >Furthermore, there is a "constructor-arg" tag within the "bean" tag now, to pass specific beans or values to constructor arguments. "constructor-arg" can specify generic values that get matched by type, or values for a specific argument via its "index" attribute. This means that we can handle any kind of constructor, be it with bean references, simple values, lists, maps, etc. We can also easily handle multiple constructor arguments of the same type, i.e. 2 DataSource arguments or 2 String values (in contrast to the current Pico version)! > > Good stuff. Aside from the marketing, even if you prefer the no-arg constructor, javabeans style, if you're working with existing classes sometimes you have no choice. > >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: Rob B. <rob...@ve...> - 2003-11-09 22:53:41
|
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 |
|
From: Rod J. <rod...@in...> - 2003-11-09 22:47:53
|
Juergen,
I'll look more closely at the details tomorrow, but this is very good news!
An important enhancement for M3.
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.
Regards,
Rod
----- Original Message -----
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Sunday, November 09, 2003 9:47 PM
Subject: [Springframework-developer] Type 3 IoC support
Everybody,
I'm pleased to announce that a Spring bean factory is now capable of
handling Type 3 IoC components! As the most important feature, I've
introduced autowire="constructor" for autowiring constructor arguments by
type, just like autowire="byType" does for bean properties.
Furthermore, there is a "constructor-arg" tag within the "bean" tag now, to
pass specific beans or values to constructor arguments. "constructor-arg"
can specify generic values that get matched by type, or values for a
specific argument via its "index" attribute. This means that we can handle
any kind of constructor, be it with bean references, simple values, lists,
maps, etc. We can also easily handle multiple constructor arguments of the
same type, i.e. 2 DataSource arguments or 2 String values (in contrast to
the current Pico version)!
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.
As an example, the XML bean definition from the test case:
<beans>
<bean id="rod1"
class="org.springframework.beans.factory.xml.ConstructorDependenciesBean">
<constructor-arg><ref bean="other"/></constructor-arg>
<constructor-arg><ref bean="kerry2"/></constructor-arg>
</bean>
<bean id="rod2"
class="org.springframework.beans.factory.xml.ConstructorDependenciesBean">
<constructor-arg index="1"><ref bean="kerry1"/></constructor-arg>
<constructor-arg index="0"><ref bean="kerry2"/></constructor-arg>
<constructor-arg><ref bean="other"/></constructor-arg>
</bean>
<bean id="rod3"
class="org.springframework.beans.factory.xml.ConstructorDependenciesBean"
autowire="constructor">
<constructor-arg><ref bean="kerry2"/></constructor-arg>
</bean>
<bean id="rod4"
class="org.springframework.beans.factory.xml.DerivedConstructorDependenciesB
ean">
<constructor-arg index="1"><ref bean="kerry1"/></constructor-arg>
<constructor-arg index="3"><value>99</value></constructor-arg>
<constructor-arg><ref bean="other"/></constructor-arg>
<constructor-arg index="4"><value>myname</value></constructor-arg>
<constructor-arg index="0"><ref bean="kerry2"/></constructor-arg>
</bean>
<bean id="kerry1" class="org.springframework.beans.TestBean">
<property name="name">
<value>Kerry</value>
</property>
</bean>
<bean id="kerry2" class="org.springframework.beans.TestBean">
<property name="name">
<value>Kerry</value>
</property>
</bean>
<bean id="other" class="org.springframework.beans.factory.LifecycleBean"/>
</beans>
Juergen
-------------------------------------------------------
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: Brian M. <br...@ap...> - 2003-11-10 01:22:00
|
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
|
|
From: Rod J. <rod...@in...> - 2003-11-10 08:49:29
|
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 -----
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
>
|
|
From: Brian M. <mcc...@fo...> - 2003-11-10 12:24:31
|
On Monday, November 10, 2003, at 03:49 AM, Rod Johnson wrote: > Brian, > > We have an article on the Spring site about Type 2 and 3 comparison. Cool, I was looking (via google) for just such a discussion. I will check it out. > 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 understand, and am not trying to argue (for the sake of argument) - it is a serious question as I do not believe I have all of the answers by a long shot (particularly in lightweight IoC containers). My tendency is to believe you are right -- as you are deeper into the problem than I am and understand it better. I don't see it though, and I want to see it. > 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. Hmm. I need to go read the article before I say anything more =) Thank you (very much) for helping me! -Brian |
