Listing 5-5. Using JSR-250 @PostConstruct Annotation
package com.apress.prospring3.ch5.lifecycle;
import javax.annotation.PostConstruct;
// Other import statements omitted
public class SimpleBeanWithJSR250 {
// Codes omitted
@PostConstruct
public void init() throws Exception {
// Rest of codes omitted
}
}
The program is exactly the same as the SimpleBean; just apply the @PostConstruct annotation
before the init() method. Note that you can assign any name to the method.
For the configuration, we can use the one used by the interface mechanism (Listing 5-4). However,
since we are using annotation, we need to add the context namespace and the <context:annotation-
driven> tag into the configuration file.
Afterward, run the program, and you will see the same output as other mechanisms.
As we discussed earlier, all three approaches have their benefits and drawbacks. Using an
initialization method, you have the benefit of keeping your application decoupled from Spring, but you
have to remember to configure the initialization method for every bean that needs it. Using
InitializingBean, you have the benefit of being able to specify the initialization callback once for all
instances of your bean class, but you have to couple your application to do so. Using annotations, you
need to apply the annotation to the method and make sure that the IoC container supports JSR-250. In
the end, you should let the requirements of your application drive the decision about which approach to
use. If portability is an issue, then use the initialization or annotation method; otherwise, use the
InitializingBean interface to reduce the amount of configuration your application needs and the
chance of errors creeping into your application because of misconfiguration.
Order of Resolution
You can use all mechanisms on the same bean instance. In this case, Spring invokes the method
annotated with @PostConstruct first and then InitializingBean.afterPropertiesSet(), followed by your
initialization method. This can be useful if you have an existing bean that performs some initialization in
a specific method but you need to add some more initialization code when you use Spring.
Hooking into Bean Destruction
When using an ApplicationContext implementation that wraps the DefaultListableBeanFactory
interface (such as GenericXmlApplicationContext, via the
GenericApplicationContext.getDefaultListableBeanFactory() method), you can signal to the
BeanFactory that you want to destroy all singleton instances with a call to
ConfigurableBeanFactory.destroySingletons(). Typically, you do this when your application shuts
down, and it allows you to clean up any resources that your beans might be holding open, thus
allowing your application to shut down gracefully. This callback also provides the perfect place to flush
any data you are storing in memory to persistent storage and to allow your beans to end any long-
running processes they may have started.
To allow your beans to receive notification that destroySingletons() has been called, you have three
options, all similar to the mechanisms available for receiving an initialization callback. The destruction
Search WWH :
Custom Search
Previous Page
Spring Framework 3 Topic Index
Next Page
Spring Framework 3 Bookmarks
Home