Spring Context and Bean Lifecycle callbacks: practical examples of usage

Question

I've a little experience in Spring. And I wondering about the amount of callbacks in Spring Context/Bean Lifecycle. I've never used them, and can imaging situations in which the most of them are needed.

My question is: can you provide for each callback at least one example of usage? Means situations when you need that callback.

Conext callbacks:

Bean callbacks:

P.S.:

It is clear for me when majority of callbacks are calling, or what one or another implementation of ApplicationContext was written for. But I can't figure out why someone may want to profit from that callback\implementation. For example:

• AbstractRefreshableApplicationContext is using to change bean configurations on fly. But Why? In which situation I may want to change bean's configuration on fly?
• afterPropertiesSet callback, obviously is invoked after all bean's properties are setted :) But why I should know about that, and when I should (may want) use it?

Answer 1

can you provide for each callback at least one example of usage?

Look at the javadoc for each of the interfaces, check any of the implementing classes for their purpose and look up their source code for their implementation.

A typical bean definition would be

<bean id="someBean" class="com.example.beans.SomeBean">
    <property name="someProperty" value="42" />
    <property name="other" value="I will always love you." />
</bean>

with a class like

public class SomeBean {
    private String someProperty;
    private String other;
    public void setSomeProperty(String someProperty) {
        this.someProperty = someProperty;
    }
    public void setOther(String other) {
        this.other = other;
    }
}

But some times you have classes where you need to perform some logic based on the properties set

public class SomeBean {
    private String someProperty;
    private String other;
    public void setSomeProperty(String someProperty) {
        this.someProperty = someProperty;
    }
    public void setOther(String other) {
        this.other = other;
    }
    public void init() {
        Thread thread = new Thread(new Runnable() {
            public void run() {
                // for example
                // send the two property values to some external service
            }
        });
        thread.start();
    }
}

This logic can only be performed after the properties have been set. In that case, you can have your class implement the InitializingBean interface (old school)

public class SomeBean implements InitializingBean {
    private String someProperty;
    private String other;
    public void setSomeProperty(String someProperty) {
        this.someProperty = someProperty;
    }
    public void setOther(String other) {
        this.other = other;
    }
    public void init() {
        Thread thread = new Thread(new Runnable() {
            public void run() {
                // for example
                // send the two property values to some external service
            }
        });
        thread.start();
    }
    public void afterPropertiesSet() throws Exception {
        init();
    }
}

Or annotate it with @PostConstruct (new school)

public class SomeBean implements InitializingBean {
    private String someProperty;
    private String other;
    public void setSomeProperty(String someProperty) {
        this.someProperty = someProperty;
    }
    public void setOther(String other) {
        this.other = other;
    }
    @PostConstruct
    public void init() {
        Thread thread = new Thread(new Runnable() {
            public void run() {
                // for example
                // send the two property values to some external service
            }
        });
        thread.start();
    }
}

This is just an example. The InitializingBean interface is often used along with the FactoryBean interface. It helps to initialize the factory before it produces an object. For more example, see the javadoc of both of those interfaces and look up the source code of the various implementing classes. Do the same for the other *Aware interfaces.

As for AbstractRefreshableApplicationContext, some times you need to refresh() your ApplicationContext. This can happen because you want to reload an XML configuration or because your environment has changed, but you don't want to stop/re-start the application.