- @PostContruct - This annotation is applied to a method to indicate that it should be invoked after all dependency injection is complete.
- @PreDestroy - This is applied to a method to indicate that it should be invoked before the bean is removed from the Spring context, i.e. just before it’s destroyed.
- @Resource - This duplicates the functionality of @Autowired combined with @Qualifier as you get the additional benefit of being able to name which bean you’re injecting, without the need for two annotations.
This blog takes a quick look at the first annotation in the list @PostConstruct, demonstrating how it’s applied and comparing it to the equivalent InitializingBean interface.
InitializingBean has one method, afterPropertiesSet(), and it does what it says on the tin. The afterPropertiesSet() method is called after Spring has completed wiring things together. The code snippet below demonstrates how InitializingBean is implemented.
public class ImplementInitializingBean implements InitializingBean {
private boolean result;
public String businessMethod() {
System.out.println("Inside - ImplementInitializingBean");
return "InitializingBeanResult";
}
/**
* This is part of the InitializingBean interface - called after the bean has been set-up. Use this method to check that the
* bean has been set-up correctly. Also so use it to configure external resources such as databases etc.
*/
@Override
public void afterPropertiesSet() throws Exception {
result = true;
System.out.println("In aferPropertiesSet() - check the set-up of the bean.");
}
public boolean getResult() {
return result;
}
}
Annotations are supposed to make life easier, but do they in this case? The first thing to do is to tell Spring to use annotations by adding the following to your Spring config file:
<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd"> <!-- Scans the classpath of this application for annotated beans starting at this point --> <context:component-scan base-package="jsr250annotations" /> </beans>
All three annotation used in the sample: @Component, @Autowired and @PostConstruct are activated by the context:component-scan element.
However if only @Autowired and @PostConstruct are required then this can be replaced by context:annotation-config.
Note that if you were writing a larger web-app, then you would use context:component-scan in conjunction with mvc:annotation-driven for the complete set of MVC annotations.
Having setup the application, you can now use the @PostConstruct annotation.
@Component
public class ImplementPostConstruct implements MyPostConstructExample {
private boolean result;
@Override
public String businessMethod() {
System.out.println("Inside - ImplementPostConstruct");
return "ImplementPostConstruct";
}
/**
* @PostConstruct means that this is called after the bean has been set-up.
* Use this method to check that the bean has been set-up
* correctly. Also so use it to configure external resources
* such as databases etc.
*/
@PostConstruct
public void postConstruct() {
result = true;
System.out
.println("In postConstruct() - check the set-up of the bean.");
}
@Override
public boolean getResult() {
return result;
}
}
This is tested using the JUnit Test below:
@Test
public void postConstructTest() {
instance1 = ctx.getBean(ImplementPostConstruct.class);
String result = instance1.businessMethod();
assertEquals("ImplementPostConstruct", result);
boolean var = instance1.getResult();
assertTrue(var);
}
The two clumps of code above do the same thing with postConstruct() being called at the same time asafterPropertiesSet(). It's easy to see that annotations look neater, but are they also more difficult to setup? I'll let you be the judge of that. Personally, I prefer the older interfaced based method: it's well known, used internally by Spring, and switched on by default, but I guess that it's a matter of choice. I've been advised by Chris Beams - one of the Guys at Spring - that "The Spring team recommends the use of @PostConstruct over InitializingBean for typical application-level components when using Spring 2.5 or greater as this allows for the most flexibility, portability and general benefits of "plain old Java object" design.
* note that annotation processing is enabled by default with Spring 3.0's AnnotationConfigApplicationContext, which provides an alternative to the traditional XML-based application contexts such as ClassPathXmlApplicationContext".
...which is a fair point.
No comments:
Post a comment