org.springframework.context

## Interface Lifecycle

- All Known Subinterfaces:
    ConfigurableApplicationContext, ConfigurablePortletApplicationContext, ConfigurableWebApplicationContext, LifecycleProcessor, SmartLifecycle
  All Known Implementing Classes:
    AbstractApplicationContext, AbstractJmsListeningContainer, AbstractMessageListenerContainer, AbstractPollingMessageListenerContainer, AbstractRefreshableApplicationContext, AbstractRefreshableConfigApplicationContext, AbstractRefreshablePortletApplicationContext, AbstractRefreshableWebApplicationContext, AbstractXmlApplicationContext, AnnotationConfigApplicationContext, AnnotationConfigWebApplicationContext, ClassPathXmlApplicationContext, DefaultLifecycleProcessor, DefaultMessageListenerContainer, DefaultMessageListenerContainer102, FileSystemXmlApplicationContext, GenericApplicationContext, GenericMessageEndpointManager, GenericWebApplicationContext, GenericXmlApplicationContext, JmsMessageEndpointManager, ResourceAdapterApplicationContext, SchedulerFactoryBean, SimpleMessageListenerContainer, SimpleMessageListenerContainer102, StaticApplicationContext, StaticPortletApplicationContext, StaticWebApplicationContext, TimerManagerAccessor, TimerManagerFactoryBean, TimerManagerTaskScheduler, XmlPortletApplicationContext, XmlWebApplicationContext

      public interface Lifecycle

  Interface defining methods for start/stop lifecycle control. The typical use case for this is to control asynchronous processing.

  Can be implemented by both components (typically a Spring bean defined in a Spring `BeanFactory`) and containers (typically a Spring `ApplicationContext`). Containers will propagate start/stop signals to all components that apply.

  Can be used for direct invocations or for management operations via JMX. In the latter case, the `MBeanExporter` will typically be defined with an `InterfaceBasedMBeanInfoAssembler`, restricting the visibility of activity-controlled components to the Lifecycle interface.

  Note that the Lifecycle interface is only supported on top-level singleton beans. On any other component, the Lifecycle interface will remain undetected and hence ignored. Also, note that the extended `SmartLifecycle` interface provides more sophisticated integration with the container's startup and shutdown phases.

  Since:
    2.0
  Author:
    Juergen Hoeller
  See Also:
    `SmartLifecycle`, `ConfigurableApplicationContext`, `AbstractMessageListenerContainer`, `SchedulerFactoryBean`

- - ### Method Summary

    Methods
    Modifier and Type | Method and Description
    --- | ---
    `boolean` | `isRunning()` Check whether this component is currently running.
    `void` | `start()` Start this component.
    `void` | `stop()` Stop this component, typically in a synchronous fashion, such that the component is fully stopped upon return of this method.

- - ### Method Detail

    - #### start

          void start()

      Start this component. Should not throw an exception if the component is already running.

      In the case of a container, this will propagate the start signal to all components that apply.

    - #### stop

          void stop()

      Stop this component, typically in a synchronous fashion, such that the component is fully stopped upon return of this method. Consider implementing `SmartLifecycle` and its `stop(Runnable)` variant in cases where asynchronous stop behavior is necessary.

      Should not throw an exception if the component isn't started yet.

      In the case of a container, this will propagate the stop signal to all components that apply.

      See Also:
        `SmartLifecycle.stop(Runnable)`

    - #### isRunning

          boolean isRunning()

      Check whether this component is currently running.

      In the case of a container, this will return `true` only if all components that apply are currently running.

      Returns:
        whether the component is currently running