JBoss.org Community Documentation

5.4. Lifecycle callbacks

In addition to applying aspects to beans that we instantiate using the microcontainer we can also add behaviour during the deployment and undeployment process. As you may recall from the Direct access section of Chapter 4, 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 create method, if defined on the bean, has been called.

  • START - the start method, if defined on 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.


The CREATE and START states are included in order to allow services that used to be implemented as MBeans in JBoss AS 3.x and 4.x to function correctly when implemented as beans in JBoss AS 5.x. If you do not define any corresponding create/start methods in your bean then it will simply pass straight through these states.

Together these states represent the bean's lifecycle and using an additional set of <aop> elements you can define a number of callbacks to be applied to any point:

<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

Just like the <bean> element and the <aop:aspect> element the <aop:lifecycle-> elements contain name and class attributes. These allow the microcontainer to create an instance of the callback class and give it a name so that it can be used as beans enter/leave the relevant state during deployment and undeployment. You can specify which beans are affected by the callback using the classes attribute:

<aop:lifecycle-install xmlns:aop="urn:jboss:aop-beans:1.0"

Here we have specified that additional logic in the LifecycleCallback class should be 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.

In order for the callback class to work it must contain install and uninstall methods that take ControllerContext as a parameter:

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 will be called during the bean's deployment and the uninstall method during its undeployment.


Although we are adding behaviour to the deployment and undeployment process using callbacks we are not actually using AOP to achieve this. The reason we have included them in this section, and the reason why they are part of the aop XML schema, is that they use the pointcut expression functionality of JBoss AOP to determine which bean classes they should apply to. We have already shown how the classes attribute allows you to write a shorthand pointcut expression to target annotated bean classes. Later in Part III - AOP Development we will show how it is possible to use regular pointcut expressions to target classes in a much more powerful way.