Re: [Springframework-developer] Spring Enhancement

[Daniel P. <po...@ci...>]

I thought about suggesting this a couple of weeks ago when Colin(?)
introduced the MethodInvocationFactoryBean.  I figured it would be shot
down since it basically allows someone to define scripts within a
configuration file...could be extremely useful, but also easily abused.
It would, however, virtually eliminate the need to write custom
FactoryBean implementations to simply adapt the creation of an object to
Spring's requirements for a component.  As an example, we're using
Commons-Digester in an application and we discovered that simply
defining Digesters in our Spring configuration with their relevant rule
sets eliminated the need for custom parses classes.  However, Digester
does not have a setRuleSets() method (have to call addRuleSet() multiple
times for each rule set), so we had to write a custom
DigesterFactoryBean.  Rod's suggestion would allow us to simply
define an addRuleSet method call for each ruleSet.

Consider me in favor of this addition.

Regards,
Daniel

On Mon, Dec 01, 2003 at 07:33:36PM -0500, Rob Butler wrote:
> 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