springframework-developer — Spring Framework developers list

RE: [Springframework-developer] Type 3 IoC support

[<jue...@we...>]

*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

[Springframework-developer] AOP clarification

[Rod J. <rod...@in...>]

MethodMatchers and ClassFilters abstract classes are purely intended to hold
static methods and shouldn't implement the respective interface.

Please note the comments on the MethodMatcher interface, which reflects a
flattening of the present MethodPointcut <------ DynamicMethodPointcut
inheritance relationship.

"Runtime" or dynamic class filtering doesn't make sense, as class filtering
is really only an information used for optimization when creating a proxy.

Regards,
Rod

RE: [Springframework-developer] Type 3 IoC support

[<jue...@we...>]

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

Re: [Springframework-developer] Type 3 IoC support

[<jue...@we...>]

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

[Springframework-developer] Revised AOP API proposal

[Rod J. <rod...@in...>]

All,

Here's a variant on the API API which goes down the path initially suggested
by Renaud with separate class and method designators. Apart from that it's
much the same: Advice is still almost the same.

The unit of composition is a ClassFilter or MethodMatcher. The new Pointcut
interface allows for FieldMatchers in the future.

Abstract convenience classes could make it easy to use: for example, the
RegexpPointcut could continue to implement Pointcut, with no need for the
application developer to work with a distinct ClassFilter or MethodMatcher.
I think the only downside of this proposal is ease of use, and convenience
classes can resolve that.

This also enables IntroductionAdvice to have only a ClassFilter, as Bob
wanted.

Static methods are still used to "compose" pointcuts and the finer-grained
units of composition.

Feedback please... This is an important API to get right, and time is
closing now, as we don't want this to delay M3.

Regards,
Rod

Re: [Springframework-developer] Type 3 IoC support

[Rod J. <rod...@in...>]

>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

Re: [Springframework-developer] Type 3 IoC support

[Rob B. <rob...@ve...>]

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
> =

RE: [Springframework-developer] Type 3 IoC support

[<jue...@we...>]

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

RE: [Springframework-developer] Type 3 IoC support

[<jue...@we...>]

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

RE: [Springframework-developer] Type 3 IoC support

[<jue...@we...>]

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

Re: [Springframework-developer] Type 3 IoC support

[Rod J. <rod...@in...>]

>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

Re: [Springframework-developer] Type 3 IoC support

[<jue...@we...>]

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

Re: [Springframework-developer] Type 3 IoC support

[Brian M. <mcc...@fo...>]

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

Re: [Springframework-developer] Type 3 IoC support

[Rod J. <rod...@in...>]

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
>

Re: Re: [Springframework-developer] Welcome anyone

[yanger <yan...@ho...>]

SXQgaXMgdmVyeSBnb29kLlRoZSB3b3JkcyBtZWFuIHRoZSBmcm9udHBhZ2Ugb2YgQ2hpbmVzZSBT
cHJpbmdmcmFtZXdvcmsgZm9ydW0gaW4gdGhlIHBpY3R1cmUuDQoNClRoYW5rcyBhZ2Fpbi4NCg0K
QmVzdCBSZWdhcmRzLA0KeWFuZ2VyDQp5YW5nZXIxOTk3QGhvdG1haWwuY29tDQoJCQkJCQkJMjAw
My0xMS0xMCAwOToyMDozOQ0KDQo9PT09PT09IDIwMDMtMTEtMDkgMjE6NDk6NDggWW91ciBtYWls
IGlzo7o9PT09PT09DQoNCj5JIGNyZWF0ZWQgdGhlIGltYWdlIGJ5IGp1c3QgY3V0dGluZyBhbmQg
cGFzdGluZyBmcm9tIGEgc2NyZWVuc2hvdCBvZiB5b3VyIHNpdGUuDQo+ICAgVGhlIGhhciBwYXJ0
IHdhcyB0cnlpbmcgdG8gZmlndXJlIG91dCB0aGUgcGFydHMgdG8gY3V0Lg0KPg0KPlRob21hcw0K
Pg0KPg0KPlF1b3RpbmcgeWFuZ2VyMTk5N0BuZXRzY2FwZS5uZXQ6DQo+DQo+PiBva2V5LEkgdGhp
bmsgaXQgbG9va3MgdmVyeSB3ZWxsLlRoZSBsaW5raW5nIHBpY3R1cmUgaXMgdmVyeSBiZWF1dGlm
dWwgLldobw0KPj4gZGlkIG1ha2UgaXQ/DQo+PiBUaGFuayB5b3UgLFRob21hcy4NCj4+IA0KPj4g
DQo+PiB0cmlzYmVyZ0B0cmlkYi5jb20gd3JvdGU6DQo+PiANCj4+ID5JIHB1dCBhIGxpbmsgb24g
dGhlIGhvbWUgcGFnZS4gIExldCBtZSBrbm93IGlmIGl0IGxvb2tzIE9LLCBvciBpZiBpdCBkb2Vz
DQo+PiBub3QNCj4+ID5tYWtlIHNlbnNlIC0gY2FuJ3QgZXhhY3RseSB2ZXJpZnkgd2hhdCBJIHB1
dCBvdXQgdGhlcmUuDQo+PiA+DQo+PiA+VGhvbWFzDQo+PiA+DQo+PiA+DQo+PiA+UXVvdGluZyBS
b2QgSm9obnNvbiA8cm9kLmpvaG5zb25AaW50ZXJmYWNlMjEuY29tPjoNCj4+ID4NCj4+ID4+IEdv
b2QgdG8gaGVhciB0aGlzLiBVbmZvcnR1bmF0ZWx5IEkgY2FuJ3QgcmVhZCBpdCwgYnV0IG1heWJl
IHdlIHNob3VsZA0KPj4gPj4gY29uc2lkZXIgbGlua2luZyB0byBpdCBmcm9tIHRoZSBTcHJpbmcg
aG9tZSBwYWdlIGZvciB0aG9zZSB3aG8gY2FuLg0KPj4gPj4gDQo+PiA+PiBSZWdhcmRzLA0KPj4g
Pj4gUm9kDQo+PiA+PiANCj4+ID4+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQo+PiA+
PiBGcm9tOiA8eWFuZ2VyMTk5N0BuZXRzY2FwZS5uZXQ+DQo+PiA+PiBUbzogPHNwcmluZ2ZyYW1l
d29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0Pg0KPj4gPj4gU2VudDogU2F0dXJk
YXksIE5vdmVtYmVyIDA4LCAyMDAzIDI6MjMgUE0NCj4+ID4+IFN1YmplY3Q6IFtTcHJpbmdmcmFt
ZXdvcmstZGV2ZWxvcGVyXSBXZWxjb21lIGFueW9uZQ0KPj4gPj4gDQo+PiA+PiANCj4+ID4+ID4g
SSBzZXQgdXAgYSBwcm9mZXNzaW9uYWwgQ2hpbmVzZSBTcHJpbmcgZm9ydW0gaW4gb3JkZXIgdG8g
Y29tbXVuaWNhdGUNCj4+IHdpdGgNCj4+ID4+IG90aGVyIFNwcmluZyBmYW5zIHdpdGggY2hpbmVz
ZS4gSSB3YW50IHRvIHByb3ZpZGUgYSBzaXRlIHdoZXJlIENoaW5lc2UNCj4+IGNhbg0KPj4gPj4g
c2hhcmUgc3ByaW5nIGZyYW1ld29yayBleHBlcmllbmNlIHdpdGggdGhlaXIgaG9tZSBsYW5ndWFn
ZSBhbmQgbWFrZSB0aGUNCj4+IHVzZQ0KPj4gPj4gb2Ygc3ByaW5nIG1vcmUgd2lkZWx5IGluIENo
aW5hLg0KPj4gPj4gPg0KPj4gPj4gPiBOb3cgc3ByaW5nIGZyYW1ld29yayBDaGluZXNlIEZvcnVt
IGlzIHRoZSAib25seSIgcHJvZmVzc2lvbmFsIHNwcmluZw0KPj4gZm9ydW0NCj4+ID4+IGluIENo
aW5hLiBXZWxjb21lIGFueW9uZSB3aG8gY2FuIHJlYWQgY2hpbmVzZSENCj4+ID4+ID4NCj4+ID4+
ID4gaHR0cDovL3hnbHcuNTEubmV0LzV0ZWFtL3NwcmluZ2ZyYW1ld29yaw0KPj4gPj4gPg0KPj4g
Pj4gPg0KPj4gPj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4gTWNBZmVlIFZpcnVzU2NhbiBPbmxpbmUg
ZnJvbSB0aGUgTmV0c2NhcGUgTmV0d29yay4NCj4+ID4+ID4gQ29tcHJlaGVuc2l2ZSBwcm90ZWN0
aW9uIGZvciB5b3VyIGVudGlyZSBjb21wdXRlci4gR2V0IHlvdXIgZnJlZSB0cmlhbA0KPj4gPj4g
dG9kYXkhDQo+PiA+PiA+IGh0dHA6Ly9jaGFubmVscy5uZXRzY2FwZS5jb20vbnMvY29tcHV0aW5n
L21jYWZlZS9pbmRleC5qc3A/cHJvbW89MzkzMzk3DQo+PiA+PiA+DQo+PiA+PiA+IEdldCBBT0wg
SW5zdGFudCBNZXNzZW5nZXIgNS4xIGZyZWUgb2YgY2hhcmdlLiAgRG93bmxvYWQgTm93IQ0KPj4g
Pj4gPiBodHRwOi8vYWltLmFvbC5jb20vYWltbmV3L0FpbS9yZWdpc3Rlci5hZHA/cHJvbW89Mzgw
NDU1DQo+PiA+PiA+DQo+PiA+PiA+DQo+PiA+PiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+ID4+ID4gVGhpcyBTRi5OZXQgZW1haWwg
c3BvbnNvcmVkIGJ5OiBBcGFjaGVDb24gMjAwMywNCj4+ID4+ID4gMTYtMTkgTm92ZW1iZXIgaW4g
TGFzIFZlZ2FzLiBMZWFybiBmaXJzdGhhbmQgdGhlIGxhdGVzdA0KPj4gPj4gPiBkZXZlbG9wbWVu
dHMgaW4gQXBhY2hlLCBQSFAsIFBlcmwsIFhNTCwgSmF2YSwgTXlTUUwsDQo+PiA+PiA+IFdlYkRB
ViwgYW5kIG1vcmUhIGh0dHA6Ly93d3cuYXBhY2hlY29uLmNvbS8NCj4+ID4+ID4gX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4gU3ByaW5nZnJh
bWV3b3JrLWRldmVsb3BlciBtYWlsaW5nIGxpc3QNCj4+ID4+ID4gU3ByaW5nZnJhbWV3b3JrLWRl
dmVsb3BlckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCj4+ID4+ID4gaHR0cHM6Ly9saXN0cy5zb3Vy
Y2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vc3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcg0KPj4g
Pj4gPg0KPj4gPj4gDQo+PiA+PiANCj4+ID4+IA0KPj4gPj4gDQo+PiA+PiAtLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiA+PiBUaGlzIFNG
Lk5ldCBlbWFpbCBzcG9uc29yZWQgYnk6IEFwYWNoZUNvbiAyMDAzLA0KPj4gPj4gMTYtMTkgTm92
ZW1iZXIgaW4gTGFzIFZlZ2FzLiBMZWFybiBmaXJzdGhhbmQgdGhlIGxhdGVzdA0KPj4gPj4gZGV2
ZWxvcG1lbnRzIGluIEFwYWNoZSwgUEhQLCBQZXJsLCBYTUwsIEphdmEsIE15U1FMLA0KPj4gPj4g
V2ViREFWLCBhbmQgbW9yZSEgaHR0cDovL3d3dy5hcGFjaGVjb24uY29tLw0KPj4gPj4gX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+IFNwcmluZ2Zy
YW1ld29yay1kZXZlbG9wZXIgbWFpbGluZyBsaXN0DQo+PiA+PiBTcHJpbmdmcmFtZXdvcmstZGV2
ZWxvcGVyQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KPj4gPj4gaHR0cHM6Ly9saXN0cy5zb3VyY2Vm
b3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vc3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcg0KPj4gPj4g
DQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+LS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gPlRoaXMgU0YuTmV0IGVtYWls
IHNwb25zb3JlZCBieTogQXBhY2hlQ29uIDIwMDMsDQo+PiA+MTYtMTkgTm92ZW1iZXIgaW4gTGFz
IFZlZ2FzLiBMZWFybiBmaXJzdGhhbmQgdGhlIGxhdGVzdA0KPj4gPmRldmVsb3BtZW50cyBpbiBB
cGFjaGUsIFBIUCwgUGVybCwgWE1MLCBKYXZhLCBNeVNRTCwNCj4+ID5XZWJEQVYsIGFuZCBtb3Jl
ISBodHRwOi8vd3d3LmFwYWNoZWNvbi5jb20vDQo+PiA+X19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCj4+ID5TcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyIG1h
aWxpbmcgbGlzdA0KPj4gPlNwcmluZ2ZyYW1ld29yay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9y
Z2UubmV0DQo+PiA+aHR0cHM6Ly9saXN0cy5zb3VyY2Vmb3JnZS5uZXQvbGlzdHMvbGlzdGluZm8v
c3ByaW5nZnJhbWV3b3JrLWRldmVsb3Blcg0KPj4gPg0KPj4gDQo+PiBfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IE1j
QWZlZSBWaXJ1c1NjYW4gT25saW5lIGZyb20gdGhlIE5ldHNjYXBlIE5ldHdvcmsuDQo+PiBDb21w
cmVoZW5zaXZlIHByb3RlY3Rpb24gZm9yIHlvdXIgZW50aXJlIGNvbXB1dGVyLiBHZXQgeW91ciBm
cmVlIHRyaWFsDQo+PiB0b2RheSENCj4+IGh0dHA6Ly9jaGFubmVscy5uZXRzY2FwZS5jb20vbnMv
Y29tcHV0aW5nL21jYWZlZS9pbmRleC5qc3A/cHJvbW89MzkzMzk3DQo+PiANCj4+IEdldCBBT0wg
SW5zdGFudCBNZXNzZW5nZXIgNS4xIGZyZWUgb2YgY2hhcmdlLiAgRG93bmxvYWQgTm93IQ0KPj4g
aHR0cDovL2FpbS5hb2wuY29tL2FpbW5ldy9BaW0vcmVnaXN0ZXIuYWRwP3Byb21vPTM4MDQ1NQ0K
Pj4gDQo+PiANCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0NCj4+IFRoaXMgU0YuTmV0IGVtYWlsIHNwb25zb3JlZCBieTogQXBhY2hlQ29u
IDIwMDMsDQo+PiAxNi0xOSBOb3ZlbWJlciBpbiBMYXMgVmVnYXMuIExlYXJuIGZpcnN0aGFuZCB0
aGUgbGF0ZXN0DQo+PiBkZXZlbG9wbWVudHMgaW4gQXBhY2hlLCBQSFAsIFBlcmwsIFhNTCwgSmF2
YSwgTXlTUUwsDQo+PiBXZWJEQVYsIGFuZCBtb3JlISBodHRwOi8vd3d3LmFwYWNoZWNvbi5jb20v
DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4g
U3ByaW5nZnJhbWV3b3JrLWRldmVsb3BlciBtYWlsaW5nIGxpc3QNCj4+IFNwcmluZ2ZyYW1ld29y
ay1kZXZlbG9wZXJAbGlzdHMuc291cmNlZm9yZ2UubmV0DQo+PiBodHRwczovL2xpc3RzLnNvdXJj
ZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9zcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyDQo+PiAN
Cj4NCj4NCj4NCj4NCj4NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tDQo+VGhpcyBTRi5OZXQgZW1haWwgc3BvbnNvcmVkIGJ5OiBBcGFjaGVD
b24gMjAwMywNCj4xNi0xOSBOb3ZlbWJlciBpbiBMYXMgVmVnYXMuIExlYXJuIGZpcnN0aGFuZCB0
aGUgbGF0ZXN0DQo+ZGV2ZWxvcG1lbnRzIGluIEFwYWNoZSwgUEhQLCBQZXJsLCBYTUwsIEphdmEs
IE15U1FMLA0KPldlYkRBViwgYW5kIG1vcmUhIGh0dHA6Ly93d3cuYXBhY2hlY29uLmNvbS8NCj5f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPlNwcmluZ2Zy
YW1ld29yay1kZXZlbG9wZXIgbWFpbGluZyBsaXN0DQo+U3ByaW5nZnJhbWV3b3JrLWRldmVsb3Bl
ckBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCj5odHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9s
aXN0cy9saXN0aW5mby9zcHJpbmdmcmFtZXdvcmstZGV2ZWxvcGVyDQo+Lg0KDQo9ID0gPSA9ID0g
PSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0NCg0KDQo=

Re: [Springframework-developer] Type 3 IoC support

[Brian M. <br...@ap...>]

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

Re: [Springframework-developer] Type 3 IoC support

[Rob B. <rob...@ve...>]

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

Re: [Springframework-developer] Type 3 IoC support

[Rod J. <rod...@in...>]

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

Re: [Springframework-developer] Type 3 IoC support

[Colin S. <col...@ex...>]

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

RE: [Springframework-developer] Type 3 IoC support

[Alef A. \(JTeam\) <al...@jt...>]

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

[Springframework-developer] Type 3 IoC support

[<jue...@we...>]

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

[Springframework-developer] Re: Re: AOP API proposal

[roger h. <apo...@sn...>]

Hi Rod

Just realised that I failed to answer you previous question...

> Are declared interfaces those that the IntroductionInterceptor really
> implements. (E.g. the case when the DelegatingIntroductionInterceptor uses
> itself as delegate?) In that case, can't they be queried using
> introspection?
Yes - they can.

From the point of view of the public IntroductionInterface the current
method getIntroducedInterfaces() should become redundant under the scheme I
am suggesting - so the interface should become just:

public IntroductionInterceptor extends Interceptor {

     Class getDeclaredInterface();         // single declared interface

}

I've obviously been confusing myself with the details of the current
implementation...

More apologies

Roger



"Rod Johnson" <rod...@in...> wrote in message
news:213d01c3a6d6$8a7fcf70$3800a8c0@chopin...
> Roger,
>
> I'm still not entirely sure I understand what you're driving at.
>
> I think the problem is that I don't quite get the distinction between
> "declared" and "implemented" interfaces.
>
> Are declared interfaces those that the IntroductionInterceptor really
> implements. (E.g. the case when the DelegatingIntroductionInterceptor uses
> itself as delegate?) In that case, can't they be queried using
> introspection?
>
> Are "implemented" interfaces the present getIntroducedInterfaces()?
>
> > When defining an IntroductionAdvice and an IntroductionInterceptor, how
> > about the use of a single Declared Interface, rather than a list of
> > Implemented Interfaces, ie:
> >
> > public interface IntroductionAdvice extends Advice {
> >
> >     IntroductionInterceptor getIntroductionInterceptor();
> >
> >     Class getInterface();      // single declared interface
> >
> > }
> >
> > public IntroductionInterceptor extends Interceptor {
> >
> >     Class getDeclaredInterface();         // single declared interface
> >
> >     Class[] getIntroducedInterfaces()   // as at present
> >
> > }
>
> I think there are occasions when we might want to introduce multiple
> interfaces, or (in odd cases) interfaces specified in the advice, not the
> interceptor.  To take a rather contrived example, I might have a
> RemoteException interceptor that throws RemoteException on every method
call
> if the signature has "throws RemoteException", for use in a test
> environment. I could introduce this with an advice specifying that the
> introduced interfaces should be MyRemoteEjbBusinessInterface, which the
> generic test RemoteExceptionIntroductionInterceptor has never heard of.
>
> Would it be possible to do what you want with an abstract implementation
of
> IntroductionInterceptor (probably a subclass of
> DelegatingIntroductionInterceptor), rather than with the core interfaces?
> This could enforce a single introduced class and provide a method
returning
> it.
>
> 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] Re: Re: AOP API proposal

[roger h. <apo...@sn...>]

Rod

Let me try and explain myself more clearly - ever hopeful...

> Are "implemented" interfaces the present getIntroducedInterfaces()?
yes.

The 'declared' interface would be a single interface for which an
introduction interceptor contracts to provide an implementation.  The
'implemented' interfaces would be the full set of superinterfaces for  the
'declared' one.

What I am after is the mechanism for an IntroductionAdvice and an
IntroductionInterceptor to be able to specify a set of requested interfaces,
by referring to a single type name - this being the 'declared' type - for
which the introduction contracts to supply the implementation.

The point being that many IntroductionInterceptors may have many
'implemented' interfaces in common - in my previous example InterceptorOne
and IntercptorTwo both implemented interfaces Ia and Ib.  So by forcing an
IntroductionInterceptor to provide a single 'declared' interface type, that
collects all the interfaces that it actually implements, I am now able to
use that 'single type name', as a selector for an actual instance of an
IntroductionInterceptor - ie i can ask a factory for an interceptor that
declares it will deliver an implementation for the collection of interfaces
named Ib, or Ic, rather than asking for something that can deliver a pair of
super interfaces Ia and Ib, which in this example is actually still an
ambiguous request.

In short, I want to be able to use the name of a single declared 'interface'
to refer to the particular collection of interfaces that is actually being
implemented.  For this to happen, the IntroductionInterceptor needs to state
what the 'declared' interface is, and the IntroductionAdvice can then refer
to it.

The sort of use case I have in mind is as follows.  If the
IntroductionAdvice were to specify a 'declared' interface, but not an
IntroductionInterceptor, then a bean factory could check whether an
IntroductionFactoryBean was available to match this 'declared' interface
name.  If so, then the corresponding IntroductionInterceptor could be
retrieved from the factory bean, and we are in business - we are wiring up
an interceptor chain by suppling requests for 'named interface types', as
opposed to the current 'named interceptors'.  Of course, the binding of the
IntroductionFactoryBeans, or the IntroductionInterceptors to the interface
names can be externalised into the bean config file, as usual.

The larger picture is about being able to use the interface names to wire up
the Proxy beans, as well as the interceptor names.

Is this any clearer ?

> I think there are occasions when we might want to introduce multiple
> interfaces, or (in odd cases) interfaces specified in the advice, not the
> interceptor.  To take a rather contrived example, I might have a
> RemoteException interceptor that throws RemoteException on every method
call
> if the signature has "throws RemoteException", for use in a test
> environment. I could introduce this with an advice specifying that the
> introduced interfaces should be MyRemoteEjbBusinessInterface, which the
> generic test RemoteExceptionIntroductionInterceptor has never heard of.

Could you please elaborate on this example - it might help to clarify my
understanding of the use cases you envisage ?  In particular I don't
understand what you mean by interfaces specified in the advice, not in the
interceptor ?   I was imagining that the Advice was declaring precisely the
interfaces that the interceptor should deliver - the point of discussion
being just how these were being named - if it is otherwise - how does it
work - I am definitely gapping, as the americans would say ;)

Have you committed a copy of the code yet - maybe looking at that would help
me understand better ?

Thanks for your patience

Roger


"Rod Johnson" <rod...@in...> wrote in message
news:213d01c3a6d6$8a7fcf70$3800a8c0@chopin...
> Roger,
>
> I'm still not entirely sure I understand what you're driving at.
>
> I think the problem is that I don't quite get the distinction between
> "declared" and "implemented" interfaces.
>
> Are declared interfaces those that the IntroductionInterceptor really
> implements. (E.g. the case when the DelegatingIntroductionInterceptor uses
> itself as delegate?) In that case, can't they be queried using
> introspection?
>
> Are "implemented" interfaces the present getIntroducedInterfaces()?
>
> > When defining an IntroductionAdvice and an IntroductionInterceptor, how
> > about the use of a single Declared Interface, rather than a list of
> > Implemented Interfaces, ie:
> >
> > public interface IntroductionAdvice extends Advice {
> >
> >     IntroductionInterceptor getIntroductionInterceptor();
> >
> >     Class getInterface();      // single declared interface
> >
> > }
> >
> > public IntroductionInterceptor extends Interceptor {
> >
> >     Class getDeclaredInterface();         // single declared interface
> >
> >     Class[] getIntroducedInterfaces()   // as at present
> >
> > }
>
> I think there are occasions when we might want to introduce multiple
> interfaces, or (in odd cases) interfaces specified in the advice, not the
> interceptor.  To take a rather contrived example, I might have a
> RemoteException interceptor that throws RemoteException on every method
call
> if the signature has "throws RemoteException", for use in a test
> environment. I could introduce this with an advice specifying that the
> introduced interfaces should be MyRemoteEjbBusinessInterface, which the
> generic test RemoteExceptionIntroductionInterceptor has never heard of.
>
> Would it be possible to do what you want with an abstract implementation
of
> IntroductionInterceptor (probably a subclass of
> DelegatingIntroductionInterceptor), rather than with the core interfaces?
> This could enforce a single introduced class and provide a method
returning
> it.
>
> 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/

Re: [Springframework-developer] AOP API proposal

[Colin S. <col...@ex...>]

I like this. I've only used the existing apis in some toy applications, 
as well as trying out AspectJ, so I can't say I have very much 
real-world experience with AOP but this feels pretty usable to me.

W/regards to Bob's (I think) comment about the naming for some of the 
stuff, I personally don't have any problem with  resuing AspectJ names, 
as long as the sematics are actually the same. As long as that's the 
case, I think a lot of people can actually benefit if they've used 
AspectJ before, or if they've read some of the AspectJ related articles 
out there, as they don't have to learn new names for the same things, of 
figure out what the differences are.

Regards,
Colin


Rod Johnson wrote:

>I attach a proposal for a revised AOP API. (Use wordwrap.)
>
>This incorporates several of Bob's suggestions, but isn't a radical
>overturning of present Spring AOP concepts.
>
>I think it achieves the following major goals:
>
>- enable pointcut and interceptor reuse, independently
>- support pointcut composition
>- allow optimization by creating pointcuts that exclude whole classes
>without the need to check at method level
>- improve the introduction mechanism
>- allow the packaging of multiple advices into an Aspect. (In the future;
>I'm not planning to implement that now.)
>
>I've already implemented it: this is not to mean that it's set in stone, but
>that it's feasible.
>
>Comments, please.
>
>I think it's important that M3 has a new, and stable, AOP API. This means
>that we have to finalize this in the next few days.
>
>Regards,
>Rod
>  
>
>------------------------------------------------------------------------
>
>
>Spring AOP API proposal. Classes and interfaces are unchanged unless noted. The fundamental implementation strategy won't really need to change at all.
>
>I have all AOP tests passing with the following API, so it's technically feasible.
>
>
>1. Advice
>
>An Advice holds a pointcut and interceptor, allowing reuse of both. There are distinct Advice classes for interception and introduction.
>
>
>
>Base class used to hold Pointcut and for inclusion in an Aspect (see 6).
>
>public abstract interface Advice {
>
>	Pointcut getPointcut();
>	
>	// Aspect getAspect();
>
>}
>
>
>
>
>Advice usable for method or other interception. Spring will support only method interception:
>
>
>public interface InterceptionAdvice extends Advice {
>	
>	Interceptor getInterceptor();
>	
>
>}
>
>
>
>Advice for an introduction. I now agree with Bob that this should specify the interfaces it supports, as an introduction interceptor may implement unknown interfaces in some cases, and we want to be able to limit the total set of interfaces exposed according to advice:
>
>
>public interface IntroductionAdvice extends Advice {
>	
>	IntroductionInterceptor getIntroductionInterceptor();
>	
>	Class[] getInterfaces();
>	
>}
>
>In this proposal, the Pointcut (inherited) should not be a MethodPointcut, but a base class pointcut as Bob suggested. While it would be nice to enforce this, I think the benefits of having a single base Pointcut outweigh it. (E.g. we can share a class pointcut between introduction and other advice).
>
>
>There would be a change on IntroductionInterceptor to allow it to implement other than a fixed set of interfaces:
>
>
>public IntroductionInterceptor extends Interceptor {
>
>	boolean implementsInterface(Interface intf);
>	
>}
>
>
>
>2. Pointcuts
>
>
>public interface Pointcut {
>
>	
>	boolean applies(Class targetClass);     //, AttributeRegistry attributeRegistry);
>	
>}
>
>
>public interface MethodPointcut extends Pointcut {
>
>	
>	boolean applies(Method method, Class targetClass);//, AttributeRegistry attributeRegistry);
>	
>}
>
>
>The following is unchanged from Spring at present except for the addition of a targetClass argument for consistency:
>
>public interface DynamicMethodPointcut extends MethodPointcut {
>
>	
>	boolean applies(Method method, Class targetClass, Object[] arguments);//, AttributeRegistry attributeRegistry);
>	
>}
>
>
>This inheritance hierarchy is merely to simplify pointcut authoring, and provide the ability to exclude pointcuts based on classes, as Bob wanted. A method pointcut's applicability will be checked by invoking the two applies methods, class first; a dynamic method pointcut by invoking the three. This is consistent with the present Spring approach.
>
>
>Pointcut composition will be managed by a class of static methods:
>
>public class Pointcuts {
>
>	public static Pointcut and(Pointcut[] pcs);
>	
>	public static Pointcut and(Pointcut pc1, pc2);
>	
>	
>	// The following methods will shield framework code from the pointcut hierarchy
>	
>	public static boolean canApply(Pointcut pc, Class clazz);
>	
>	public static boolean canApply(Pointcut pc, Class clazz, Method m);
>}
>
>
>A PointcutComposerFactoryBean will enable a pointcut to be exposed from a list of Pointcut for convenient use in a BeanFactory.
>
>
>4.ProxyConfig
>
>MethodPointcut replaced by Advice methods.
>
>Eventually Aspect methods may be added (see 6) but this should be backward compatible.
>
>
>
>5. AttributeRegistry
>
>**** TODO
>
>I'm undecided as to whether the AttributeRegistry should be included in pointcut method signatures.
>
>
>
>6. Aspects
>
>An aspect is a higher-level concept that will be introduced in future, and will be backward compatible. There will be new methods on ProxyConfig to handle with Aspects, but none of the Advice functionality will change.
>
>public interface Aspect {
>
>	/**
>	* @return an array of InterceptionAdvice or IntroductionAdvice
>	*/
>	Advice[] geAdvice();
>
>}
>
>
>7. Convenience classes
>
>Various implementations, including an AbstractPointcutMethodAdvice class that implements MethodPointcut (leaving subclasses to implement the applies(Method,...) method and exposes an Interceptor property. This will provide an easy migration path for current users who have implemented StaticMethodPointut: they can just change to this base class. 
>
>Migrating the test suite wasn't very hard, and the implementation changes weren't too bad either.
>  
>

Re: [Springframework-developer] Re: AOP API proposal

[Rod J. <rod...@in...>]

Roger,

I'm still not entirely sure I understand what you're driving at.

I think the problem is that I don't quite get the distinction between
"declared" and "implemented" interfaces.

Are declared interfaces those that the IntroductionInterceptor really
implements. (E.g. the case when the DelegatingIntroductionInterceptor uses
itself as delegate?) In that case, can't they be queried using
introspection?

Are "implemented" interfaces the present getIntroducedInterfaces()?

> When defining an IntroductionAdvice and an IntroductionInterceptor, how
> about the use of a single Declared Interface, rather than a list of
> Implemented Interfaces, ie:
>
> public interface IntroductionAdvice extends Advice {
>
>     IntroductionInterceptor getIntroductionInterceptor();
>
>     Class getInterface();      // single declared interface
>
> }
>
> public IntroductionInterceptor extends Interceptor {
>
>     Class getDeclaredInterface();         // single declared interface
>
>     Class[] getIntroducedInterfaces()   // as at present
>
> }

I think there are occasions when we might want to introduce multiple
interfaces, or (in odd cases) interfaces specified in the advice, not the
interceptor.  To take a rather contrived example, I might have a
RemoteException interceptor that throws RemoteException on every method call
if the signature has "throws RemoteException", for use in a test
environment. I could introduce this with an advice specifying that the
introduced interfaces should be MyRemoteEjbBusinessInterface, which the
generic test RemoteExceptionIntroductionInterceptor has never heard of.

Would it be possible to do what you want with an abstract implementation of
IntroductionInterceptor (probably a subclass of
DelegatingIntroductionInterceptor), rather than with the core interfaces?
This could enforce a single introduced class and provide a method returning
it.

Regards,
Rod