Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Doc: Lifecycle beans aren't stopped before destruction in some scenarios such as context refresh [SPR-11671] #16294

spring-projects-issues opened this issue Apr 7, 2014 · 1 comment


Copy link

@spring-projects-issues spring-projects-issues commented Apr 7, 2014

Eron Wright opened SPR-11671 and commented

It may be regarded as a sort of resource leak. When the application context is refreshed, old bean instances that implement Lifecycle are not automatically stopped. The leakage may occur silently if the application developer is not aware that some beans implement Lifecycle, and simply calls refresh.

If refresh is deliberately not integrated with Lifecycle, then consider it an error condition to call refresh on a context before stopping it.

At minimum, please improve the documentation around behavior of Lifecycle beans and context refresh.

No further details from SPR-11671

Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 27, 2014

Juergen Hoeller commented

Indeed, Lifecycle beans aren't necessarily receiving a stop() signal before destruction. If a stop point is essential for resource management in a specific bean of yours, consider implementing DisposableBean with clean-up in destroy(): This is generally advisable anyway, since the destroy call will arrive in any scenario, even aborted refresh attempts etc. Such a destroy call will also be called after stop on regular shutdown, so it needs to be prepared for both kinds of scenarios, cleaning up what's left.


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants