Learn more about the Spring ApplicationContext: As discussed in the previous
·
chapter, the ApplicationContext is an extension of the BeanFactory intended for
use in full applications. The ApplicationContext interface provides a useful set of
additional functionality, including internationalized message provision, resource
loading, and event publishing. In this chapter, we take a detailed look at the
features in addition to IoC that the ApplicationContext offers. We also jump ahead
of ourselves a little and look at how the ApplicationContext simplifies the use of
Spring when you are building web applications.
Configuration using Java classes: Prior to 3.0, Spring supported only the XML base
·
configuration with annotations for beans and dependency configuration. Starting
with 3.0, Spring offers another option for developers to configure the Spring
ApplicationContext using Java classes. We take a look at this new option in Spring
application configuration.
New features in the Spring 3.1 configuration: Spring 3.1 provides some useful new
·
features specific to configuration, such as profiles management, environment and
property source abstraction, and so on. In this section, we take a look at those
features and show how to use them to address specific configuration needs.
Spring's Impact on Application Portability
Most of the features discussed in this chapter are specific to Spring and, in many cases, are not available
in other IoC containers. Although many IoC containers offer life-cycle management functionality, they
probably do so through a different set of interfaces than Spring. If the portability of your application
between different IoC containers is truly important, then you might want to avoid using some of the
features that couple your application to Spring.
Remember, however, that by setting a constraint--that your application is portable between IoC
containers--you are losing out on the wealth of functionality Spring offers. Because you are likely to be
making a strategic choice to use Spring, it makes sense that you use it to the best of its ability.
Be careful not to create a requirement for portability out of thin air. In many cases, the end users of
your application do not care if the application can run on three different IoC containers; they just want it
to run. In our experience, it is often a mistake to try to build an application on the lowest common
denominator of features available in your chosen technology. Doing so often sets your application at a
disadvantage right from the get-go. However, if your application requires IoC container portability, then
do not see this as a drawback--it is a true requirement and, therefore, one your application should fulfill.
In Expert One-on-One: J2EE Development without EJB (Wrox, 2004), Rod Johnson and Jürgen Höller
describe these types of requirement as phantom requirements and provide a much more detailed
discussion of them and how they can affect your project.
Although using these features may couple your application to the Spring Framework, in reality you
are increasing the portability of your application in the wider scope. Consider that you are using a freely
available, open source framework that has no particular vendor affiliation. An application built using
Spring's IoC container runs anywhere Java runs. For Java enterprise applications, Spring opens up new
possibilities for portability. Spring provides many of the same capabilities as JEE and also provides
classes to abstract and simplify many other aspects of JEE. In many cases, it is possible to build a web
application using Spring that runs in a simple servlet container but with the same level of sophistication
as an application targeted at a full-blown JEE application server. By coupling to Spring, you can increase
your application's portability by replacing many features that either are vendor-specific or rely on
vendor-specific configuration with equivalent features in Spring.
Search WWH :
Custom Search
Previous Page
Spring Framework 3 Topic Index
Next Page
Spring Framework 3 Bookmarks
Home