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

[Glen M. <gr...@ve...>]

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