There are a couple of different ways to define the lifecycle callbacks using the EJB3 cartridge. This howto will provide the necessary information on how you can implement the callback handlers for entity, session and message-driven beans.
You have two basic choices on how you want to implement the lifecycle callbacks. You can annotate methods in the bean class to indicate the individual callback or you can separate out the callback implementation to a listener class for entity beans or interceptor for session and message-driven beans. These options are discussed below.
You can define any number of the following callbacks in an entity bean by modeling the appropriate stereotype on an entity operation. You can only define 1 lifecycle callback stereotype per entity operation.
| PrePersist | <<PrePersist>> | Invoked before the entity is created in the database and will cascade to all entities by way of the cascaded operation. |
| PostPersist | <<PostPersist>> | Invoked after the entity is created in the database and will cascade to all entities by way of the cascaded operation. |
| PreRemove | <<PreRemove>> | Invoked before the entity is deleted in the database and will cascade to all entities by way of the cascaded operation. |
| PostRemove | <<PostRemove>> | Invoked after the entity is deleted in the database and will cascade to all entities by way of the cascaded operation. |
| PreUpdate | <<PreUpdate>> | Occurs right before the database is updated. |
| PostUpdate | <<PostUpdate>> | Occurs immediately after the database has been updated. |
| PostLoad | <<PostLoad>> | Occurs right after the data has been loaded from the database and associated with the entity. |
Due to the limitations of the EJB3 cartridge when it comes to inheritance, you may need to assign a callback listener class to the entity. In an entity inheritance hierarchy, there are times where you do not have an implementation class for the entity and therefore do not have the ability to implement the lifecycle callback if you model the callback stereotype on the entity operation.
To separate out the callback for the entity into an entity listener class, simply model the <<Listener>> stereotype on the entity class. This will add the @EntityListener annotation to the class. The associated listener class includes all the lifecycle callbacks for the entity. The listener is generated on the first run and will never be overwritten, so you are free to add your implementation to the lifecycle callback operations.
Follow the example in the environment entry injection howto to see how you can assign lifecycle callbacks on entities.
You can define any number of the following callbacks in an session bean by modeling the appropriate stereotype on an operation. You can only define 1 lifecycle callback stereotype per session operation. The lifecycle callbacks for a stateless session bean is a subset of the lifecycle callbacks for a stateful session bean.
The following lifecycle callback for stateless session beans and the corresponding stereotype you need to model are:
| PostConstruct | <<PostConstruct>> | Invoked when the bean is first created and after the dependency injection is completed. |
| PreDestroy | <<PreDestroy>> | Invoked when the bean is removed from the pool or destroyed. |
The following lifecycle callback for stateful session beans and the corresponding stereotype you need to model are:
| PostConstruct | <<PostConstruct>> | Invoked when the bean is first created and after the dependency injection is completed. |
| PreDestroy | <<PreDestroy>> | Invoked when the bean is removed from the pool or destroyed. |
| PostActivate | <<PostActivate>> | Invoked when the bean has just been reactivated. |
| PrePassivate | <<PrePassivate>> | Invoked just before the container passivates the bean instance. |
To separate out the callback for the session bean into an interceptor class, simply model the <<Listener>> stereotype on the session bean. This will add the @Interceptors annotation to the bean base class. The associated listener/interceptor class includes all the appropriate lifecycle callbacks for the session bean. The listener is generated on the first run and will never be overwritten, so you are free to add your implementation to the lifecycle callback operations. These lifecycle methods of the interceptors must call proceed on the InvocationContext as the last execution step to invoke the next interceptor in the chain.
You can define any number of the following callbacks in a message-driven bean by modeling the appropriate stereotype on a MDB operation. You can only define 1 lifecycle callback stereotype per MDB operation.
The following lifecycle callback for stateless session beans and the corresponding stereotype you need to model are:
| PostConstruct | <<PostConstruct>> | Invoked when the bean is first created and after the dependency injection is completed. |
| PreDestroy | <<PreDestroy>> | Invoked when the bean is removed from the pool or destroyed. |
You can follow the same process as in session bean callbacks above to separate out the callback interceptor class for the message-driven bean.
For a guide on how to utilize transactions in this cartridge, click here.