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
`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