Spring/spring-framework
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Clarification: Lifecycle does not imply auto-startup semantics

Browse Source 
Issue: SPR-12855
This commit is contained in:
Juergen Hoeller
2015-03-30 21:06:12 +02:00
parent 502fa1796e
commit 7e22623758
3 changed files with 47 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
src/asciidoc/core-beans.adoc
View File

@@ -3093,9 +3093,9 @@ lifecycle requirements (e.g. starts and stops some background process):
----
Any Spring-managed object may implement that interface. Then, when the
`ApplicationContext` itself starts and stops, it will cascade those calls to all `Lifecycle`
implementations defined within that context. It does this by delegating to a
`LifecycleProcessor`:
`ApplicationContext` itself receives start and stop signals, e.g. for a stop/restart
scenario at runtime, it will cascade those calls to all `Lifecycle` implementations
defined within that context. It does this by delegating to a `LifecycleProcessor`:
[source,java,indent=0]
[subs="verbatim,quotes"]
@@ -3113,6 +3113,14 @@ Notice that the `LifecycleProcessor` is itself an extension of the `Lifecycle`
interface. It also adds two other methods for reacting to the context being refreshed
and closed.
[TIP]
====
Note that the regular `org.springframework.context.Lifecycle` interface is just a plain
contract for explicit start/stop notifications and does NOT imply auto-startup at context
refresh time. Consider implementing `org.springframework.context.SmartLifecycle` instead
for fine-grained control over auto-startup of a specific bean (including startup phases).
====
The order of startup and shutdown invocations can be important. If a "depends-on"
relationship exists between any two objects, the dependent side will start __after__ its
dependency, and it will stop __before__ its dependency. However, at times the direct