GenericXmlApplicationContext ctx = new GenericXmlApplicationContext();
ctx.load("classpath:jsr330/jsr330.xml");
ctx.refresh();
MessageRenderer renderer = ctx.getBean("messageRenderer", MessageRenderer.class);
renderer.render();
}
}
It's the same as the previous samples. Running the program will yield the following output:
You are running JSR330!
By using JSR-330, you can ease the migration into other JSR-330 compatible IoC containers (e.g.,
JEE6 compatible application servers, other DI containers such as Google Guice, etc.). However, Spring's
annotations are much more feature rich and flexible than JSR-330 annotations. Some main differences
are highlighted here:
When using Spring's @Autowired annotation, you can specify a required attribute
ˇ
to indicate that the DI must be fulfilled (you can also use Spring's @Required
annotation to declare this requirement), while for JSR-330's @Inject annotation,
there is no such equivalent. Moreover, Spring provides the @Qualifier annotation,
which allows more fine-grained control for Spring to perform autowiring of
dependencies based on qualifier name.
JSR-330 supports only singleton and nonsingleton bean scopes, while Spring
ˇ
supports more scopes, which is very useful for web applications.
In Spring, you can use the @Lazy annotation to instruct Spring to instantiate the
ˇ
bean only when requested by the application. There's no such equivalent in
JSR-330.
You can also mix and match Spring and JSR-330 annotations in the same application. However, it is
recommended that you settle on either one to maintain a consistent style for your application. One
possible way is to use JSR-330 annotations as much as possible and use Spring annotations when
required. However, this brings you fewer benefits because you still need to do quite a bit of work in
migrating to another DI container. In conclusion, Spring's annotations approach is recommended over
JSR-330 annotations given the fact that Spring's annotations are much more powerful, unless there is a
requirement that your application should be IoC container independent.
Summary
In this chapter, you saw a wide range of Spring-specific features that complement the core IoC
capabilities. You saw how to hook into the life cycle of a bean and to make it aware of the Spring
environment. We introduced FactoryBeans as a solution for IoC-enabling a wider set of classes. We also
looked at how you can use PropertyEditors to simplify application configuration and to remove the need
for artificial String-typed properties. Moreover, we finished with an in-depth look at some additional
features offered by the ApplicationContext including i18n, event publication, and resource access.
We also covered some latest features that were introduced into Spring 3.0 and 3.1, such as using Java
classes instead of XML configuration, profiles support, and the environment and property source
abstraction layer. Finally, we discussed using JSR-330 standard annotations in Spring.
So far, we have covered the main concepts of the Spring Framework and its features as a DI
container as well as other services that the core Spring Framework provides. In the next chapter and
onward, we will discuss using Spring in different specific areas such as AOP, data access, transaction
support, web application support, and so on.
Search WWH :
