Re: [Springframework-developer] Spring Enhancement

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

Rob,
=20
Spring has already been supporting a declarative "init-method" and =
"destroy-method" for quite a while, as an alternative to implementing =
InitializingBean or DisposableBean, respectively. The init method is =
called after properties population, the destroy method on factory =
shutdown. The intention behind those is exactly to be able to decouple =
classes from Spring completely.
=20
I believe those capabilities, together with constructor resolution, =
should cover 95% of everyday JavaBeans and similar components with =
non-default constructors. For anything beyond, like arbitrary method =
invocations inbetween property population, you can and should implement =
either a wrapper or a FactoryBean. It would be pretty complex to cover =
all possible scenarions here: It's probably not worth the additional =
complexity in the framework to support those final 5% with generic means =
too.
=20
BTW, a feature that Colin recently added is MethodInvokingFactoryBean, =
but that's targetting a different use case: Invoking static factory =
methods and exposing the returned object in the bean factory, for bean =
references etc. Obviously, it's not built into the bean factory core but =
rather implemented as FactoryBean.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Rob Butler
Gesendet: Mo 01.12.2003 22:32
An: spr...@li...
Betreff: [Springframework-developer] Spring Enhancement



Spring now provides the ability to instantiate an object using either a =
JavaBean no arg constructor, or any normal Java constructor.  But it =
does not support calling methods.

Also, Spring requires that a class implement the InitializingBean =
interface if it needs to perform some "setup" work after the setters =
have all been called.  This means that any class that has this need is =
tied to the Springframework.

What if the ability to call any arbitrary method was added to Spring?  =
Then users could call "afterPropertiesSet" to do "setup" work without =
having to implement the InitializingBean interface.  Ideally method =
calls could be in any order along with calls to setters.  Spring would =
then call each in order.  Thus, allowing some setters to be called, then =
some methods, then more setters if necessary.  If this is not possible, =
then methods should be called after setters.

This would allow complete decoupling of classes from Spring.  The =
InitializingBean & BeanFactoryAware interfaces would no longer be needed =
(although could remain for backwards compatibility).  This would be very =
useful when contributing code to other projects that do not want to have =
a dependency on Spring.  Also, it would allow virtually any class used =
by /developed for  another IOC framework / lightweight container to be =
used in Spring.

Thoughts?

Later
Rob



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer