Class ContainerLifeCycle

java.lang.Object
org.eclipse.jetty.util.component.AbstractLifeCycle
org.eclipse.jetty.util.component.ContainerLifeCycle
All Implemented Interfaces:
Container, Destroyable, Dumpable, Dumpable.DumpableContainer, LifeCycle
Direct Known Subclasses:
AbstractConnectionFactory, AbstractConnectionPool, AbstractConnector, AbstractHandler, AbstractHttpClientTransport, AbstractLoginService, AbstractSessionCache, AbstractSessionDataStore, AdaptiveExecutionStrategy, AttributeContainerMap, CachingSessionDataStore, ClientConnectionFactory.Info, ClientConnectionFactoryOverHTTP2, ClientConnectionFactoryOverHTTP3, ClientConnector, ClientConnector.Configurator, CompressionPool, ConfigurableSpnegoLoginService, CustomRequestLog, DefaultSessionIdManager, DelegatingThreadPool, DeploymentManager, ExecutorThreadPool, HTTP2Client, HTTP2Session, HTTP3Client, HttpClient, HttpDestination, JAASLoginService, JakartaWebSocketContainer, JakartaWebSocketShutdownContainer, JettyWebSocketFrameHandlerFactory, JettyWebSocketServerContainer, KeyStoreScanner, LeakTrackingByteBufferPool, LowResourceMonitor, ManagedSelector, OpenIdConfiguration, OpenIdLoginService, ProtocolSession, QueuedThreadPool, QuicSession, Scanner, ScanningAppProvider, SelectorManager, ServletContextHandler.ServletContainerInitializerStarter, ServletTester, WebSocketClient, WebSocketComponents, WebSocketCoreClient

@ManagedObject("Implementation of Container and LifeCycle") public class ContainerLifeCycle extends AbstractLifeCycle implements Container, Destroyable, Dumpable.DumpableContainer
A ContainerLifeCycle is an LifeCycle implementation for a collection of contained beans.

Beans can be added to the ContainerLifeCycle either as managed beans or as unmanaged beans. A managed bean is started, stopped and destroyed with the aggregate. An unmanaged bean is associated with the aggregate for the purposes of dump(), but its lifecycle must be managed externally.

When a LifeCycle bean is added without a managed state being specified the state is determined heuristically:

  • If the added bean is running, it will be added as an unmanaged bean.
  • If the added bean is !running and the container is !running, it will be added as an AUTO bean (see below).
  • If the added bean is !running and the container is starting, it will be added as a managed bean and will be started (this handles the frequent case of new beans added during calls to doStart).
  • If the added bean is !running and the container is started, it will be added as an unmanaged bean.
When the container is started, then all contained managed beans will also be started. Any contained AUTO beans will be check for their status and if already started will be switched unmanaged beans, else they will be started and switched to managed beans. Beans added after a container is started are not started and their state needs to be explicitly managed.

When stopping the container, a contained bean will be stopped by this aggregate only if it is started by this aggregate.

The methods addBean(Object, boolean), manage(Object) and unmanage(Object) can be used to explicitly control the life cycle relationship.

If adding a bean that is shared between multiple ContainerLifeCycle instances, then it should be started before being added, so it is unmanaged, or the API must be used to explicitly set it as unmanaged.

All EventListeners added via addEventListener(EventListener) are also added as beans and all beans added via an addBean(Object) method that are also EventListeners are added as listeners via a call to addEventListener(EventListener).

This class also provides utility methods to dump deep structures of objects. In the dump, the following symbols are used to indicate the type of contained object:

 SomeContainerLifeCycleInstance
   +- contained POJO instance
   += contained MANAGED object, started and stopped with this instance
   +~ referenced UNMANAGED object, with separate lifecycle
   +? referenced AUTO object that could become MANAGED or UNMANAGED.