Treat start/stop Lifecycle of beans like the init/destroy events [SPR-2325]

[spring-projects-issues]

Michael Kanaley opened SPR-2325 and commented

Spring 2.0 now supports beans implementing the Lifecycle interface. I would like to see the start/stop functionality treated identically to that of init/destroy in the following ways:

• declarative specification of start/stop methods.
  The bean element in the Spring XML configuration has init-method and destroy-method. I would like to see start-method and stop-method added so that beans are not required to implement any Spring interface to use this feature.

• preserve start/stop order
  When initializing, beans are initialized by taking dependencies into consideration. Currently the implementation of start/stop does not take order into consideration so no two Lifecycle beans could rely on any order of being started. The start order should be the same as the init order. The stop order should be the reverse of the init order.

---

Affects: 2.0 RC2

Issue Links:

• Lifecycle methods based on annotations [SPR-3828] #8508 Lifecycle methods based on annotations

[spring-projects-issues]

Rick Evans commented

• sending of an ApplicationEvent after start and before stop
  Currently init and destroy of ApplicationContexts send events as well. I would like to see this for start/stop too.

(copied from #7015)

[spring-projects-issues]

Mark Fisher commented

The order of invocation for 'start()' and 'stop()' methods now respects any 'depends-on' relationships.

Also, when the context invokes 'start()' or 'stop()' on Lifecycle beans, it now publishes events:
ComponentStartedEvent
ComponentStoppedEvent

The 'source' of each event is the Lifecycle instance.

Declarative configuration of start/stop methods is not being added to the XML, since the lifecycle behavior is in the application context (not the bean factory). However, I have created a new issue (http://opensource.atlassian.com/projects/spring/browse/SPR-3828) for providing declarative lifecycle methods via annotations and a BeanPostProcessor.

Mark

[spring-projects-issues]

Juergen Hoeller commented

Mark, I've reworked ComponentStartedEvent/ComponentStoppedEvent into ContextStartedEvent/ContextStoppedEvent, since those are arguably the more 'natural' companions to the existing ContextRefreshEvent and ContextClosedEvent classes.

Individual start/stop signals for a specific component can also go to the bean instance directly, i.e. through JMX or through custom management code; hence a ComponentStartedEvent cannot really be relied on. ContextStartedEvent on the other hand only applies to a start signal propagated by the ApplicationContext and doesn't claim control of a start signal to an individual component in the first place.

Juergen

[spring-projects-issues]

Paul Benedict commented

I agree. Correct me if wrong, but the nomenclature of "component" is being used by Spring for objects an ApplicationContext manages. I haven't seen any prior usage of "component" referring to the context itself.