1 . The container starts by creating a new instance of the singleton bean. The bean may
be instantiated on startup ( @Startup ) or as a result of another bean being instanti-
ated ( @DependsOn ). Normally, beans are instantiated lazily as they're first accessed.
2 . After the constructor has completed, the container injects the resources such as JPA
contexts, data sources, and other beans.
3 . The @PostConstruct annotated method is invoked. The bean isn't accessible
until it completes successfully.
4 . The instance is stored in memory awaiting method invocations.
5 . The client executes a business method through the business interface.
6 . The container is informed that it must shut down.
7 . The @PreDestroy callback is invoked prior to the application terminating.
The singleton session bean has the same lifecycle callbacks as the stateless session bean.
These callbacks enable you to run code after resources have been injected but before the
class receives method invocations and before the bean is handed off to garbage collection.
The callbacks are as follows:
• @PostConstruct— This is invoked right after the default constructor has ex-
ecuted and resources have been injected.
• @PreDestroy— This is invoked before the bean is destroyed. The instance will
subsequently be released to the garbage collector.
The most important thing to remember about these callbacks is that they're invoked once
at most. A singleton bean, as its name implies, is instantiated only once and it's destroyed
A singleton bean may be annotated with a @DependsOn annotation. This annotation en-
ables a bean to depend on another bean. When a bean is instantiated, any of its dependen-
cies will also be instantiated. The expectation is that when a bean depends on another bean,
that other bean will have done something to set the state of the application. The following
is the definition of the @DependsOn annotation: