Re: Remove ability to specify init-method for a bean implementing InitializingBean? (Was Re: [Springframework-developer] Spring Framework 2.0 M5 released)

[Juergen H. <ju...@in...>]

Well, you got a point there that it's very rare to see both InitializingBean
and init-method in use for the same bean. The latter is mainly intended as
non-intrusive alternative to the former.

That said, I don't really see a strong need to forbid the combo either.
After all, Spring's bean init order is not subject for arbitrary change, so
the behavior is still absolutely predictable and will remain compatible.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Glen Mazza
Sent: Thursday, June 01, 2006 8:21 PM
To: spr...@li...
Subject: Remove ability to specify init-method for a bean implementing
InitializingBean? (Was Re: [Springframework-developer] Spring Framework 2.0
M5 released)

Juergen Hoeller wrote:

> Dear Spring community,
> 
> I'm pleased to announce that Spring 2.0 M5 has been released. This 
> intermediate release paves the way for the upcoming release candidate, 
> giving early access to major new features before the 2.0 API freeze.
> 

Speaking of API freeze, Rob Harrop's Pro Spring book mentions something that
might warrant an API change for 2.0.

In Ch. 5 -> Bean Lifecycle management -> Hooking into Bean Creation -->
Order of Resolution section, he mentions functionality that allows one to
specify the "init-method" attribute for a bean that already implements
InitializingBean.  He writes:

"This can be useful if you have an existing bean that performs some
initialization in a specific method, but you need to add some more
initialization code when you use Spring. However, a better approach is to
call your bean's initialization method from afterPropertiesSet(). 
This way, if Spring changes the initialization order in a future release,
your code continues to work as it should."

I agree, also I think it is better self-documenting to see (say)
initMethod() called directly from afterPropertiesSet() instead of one not
calling the other explicitly but just having their ordering specified from
the framework.  This doesn't seem to be a design that Spring should
encourage.

I wonder if Spring 2.0 should prohibit specification of an init-method for
any class that already implements InitializingBean.  (This issue also holds
for destroy-method and DisposableBean.)  If the purpose of init-method is to
provide an ability to initialize classes for which the developer does *not*
wish to implement InitializingBean, it seems strange to allow for both to
occur.

Thanks,
Glen


-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer