5.4. Lifecycle Callbacks
In addition to applying aspects to beans that we instantiate using the Microcontainer we can also add behavior during the deployment and undeployment process. As mentinoed in Section 4.3, “Direct Access”, a bean goes through several different states as it is deployed. These include:
- NOT_INSTALLED
- the deployment descriptor containing the bean has been parsed, along with any annotations on the bean itself.
- DESCRIBED
- any dependencies created by AOP have been added to the bean, and custom annotations have been processed.
- INSTANTIATED
- an instance of the bean has been created.
- CONFIGURED
- properties have been injected into the bean, along with any references to other beans.
- CREATE
- the
createmethod, if defined in the bean, has been called. - START
- the
startmethod, if defined in the bean, has been called. - INSTALLED
- any custom install actions that were defined in the deployment descriptor have been executed and the bean is ready to access.
Important
The
CREATE and START states are included for legacy purposes. This allows services that were implemented as MBeans in previous versions of the Enterprise Platform to function correctly when implemented as beans in the Enterprise Platform 5.1. If you do not define any corresponding create/start methods in your bean, it will pass straight through these states.
These states represent the bean's lifecycle. You can define a number of callbacks to be applied to any point by using an additional set of <aop> elements:
- <aop:lifecycle-describe>
- applied when entering/leaving the DESCRIBED state
- <aop:lifecycle-instantiate>
- applied when entering/leaving the INSTANTIATED state
- <aop:lifecycle-configure>
- applied when entering/leaving the CONFIGURED state
- <aop:lifecycle-create>
- applied when entering/leaving the CREATE state
- <aop:lifecycle-start>
- applied when entering/leaving the START state
- <aop:lifecycle-install>
- applied when entering/leaving the INSTALLED state
Like the <bean> and <aop:aspect> elements, the <aop:lifecycle-> elements contain name and class attributes. The Microcontainer uses these attributes to create an instance of the
callback class, naming it so that it can be used as beans enter or leave the relevant state during deployment and undeployment. You can specify which beans are affected by the callback using the classes attribute, as shown in Example 5.5, “Using the classes Attribute”.
Example 5.5. Using the classes Attribute
<aop:lifecycle-install xmlns:aop="urn:jboss:aop-beans:1.0" name="InstallAdvice" class="org.jboss.test.microcontainer.support.LifecycleCallback" classes="@org.jboss.test.microcontainer.support.Install"> </aop:lifecycle-install>
This code specifies that additional logic in the
lifecycleCallback class is applied to any bean classes that are annotated with @org.jboss.test.microcontainer.support.Install before they enter and after they leave the INSTALLED state.
For the callback class to work, it must contain
install and uninstall methods that take ControllerContext as a parameter, as shown in Example 5.6, “Install and Uninstall Methods”.
Example 5.6. Install and Uninstall Methods
import org.jboss.dependency.spi.ControllerContext;
public class LifecycleCallback {
public void install(ControllerContext ctx) {
System.out.println("Bean " + ctx.getName() + " is being installed";
}
public void uninstall(ControllerContext ctx) {
System.out.println("Bean " + ctx.getName() + " is being uninstalled";
}
}
The
install method is called during the bean's deployment, and the uninstall method during its undeployment.
Note
Although behavior is being added to the deployment and undeployment process using callbacks, AOP is not actually used here. The pointcut expression functionality of JBoss AOP is used to determine which bean classes the behaviors apply to.
