Why Use ApplicationContext As a MessageSource?
To answer this question, we need to jump a little ahead of ourselves and look at the web application
support in Spring. The answer, in general, to this question is that you shouldn't use the
ApplicationContext as a MessageSource when doing so couples your bean to the ApplicationContext
unnecessarily (this is discussed in more detail in the next section). You should use the
ApplicationContext when you are building a web application using Spring's MVC framework.
The core interface in Spring MVC is Controller. Unlike frameworks like Struts that require you to
implement your controllers by inheriting from a concrete class, Spring simply requires that you
implement the Controller interface (or annotate your controller class with the @Controller annotation).
Having said that, Spring provides a collection of useful base classes that you will use to implement your
own controllers. All of these base classes are themselves subclasses (directly or indirectly) of the
ApplicationObjectSupport class, which is a convenient superclass for any application objects that want
to be aware of the ApplicationContext.
Remember that in a web application setting, the ApplicationContext is loaded automatically.
ApplicationObjectSupport accesses this ApplicationContext, wraps it in a MessageSourceAccessor object,
and makes that available to your controller via the protected getMessageSourceAccessor() method.
MessageSourceAccessor provides a wide array of convenient methods for working with MessageSources.
This form of "auto injection" is quite beneficial; it removes the need for all of your controllers to expose a
MessageSource property.
However, this is not the best reason for using ApplicationContext as a MessageSource in your web
application. The main reason to use ApplicationContext rather than a manually defined MessageSource
bean is that Spring does, where possible, expose ApplicationContext, as a MessageSource, to the view tier.
This means that when you are using Spring's JSP tag library, the <spring:message> tag automatically reads
messages from the ApplicationContext, and when you are using JSTL, the <fmt:message> tag does the same.
All of these benefits mean that it is better to use the MessageSource support in ApplicationContext
when you are building a web application, rather than manage an instance of MessageSource separately.
This is especially true when you consider that all you need to do to take advantage of this feature is
configure a MessageSource bean with the name messageSource.
Using MessageSource in Stand-Alone Applications
When you are using MessageSources in stand-alone applications where Spring offers no additional
support other than to nest the MessageSource bean automatically in the ApplicationContext, it is best to
make the MessageSources available using Dependency Injection. You can opt to make your bean
ApplicationContextAware, but doing so precludes their use in a BeanFactory context. Add to this the fact
that you complicate testing without any discernible benefit, and it is clear that you should stick to using
Dependency Injection to access MessageSource objects in a stand-alone setting.
The MessageSourceResolvable Interface
You can use an object that implements MessageSourceResolvable in place of a key and a set of arguments
when you are looking up a message from a MessageSource. This interface is most widely used in the
Spring validation libraries to link Error objects to their internationalized error messages. You will see an
example of how to use MessageSourceResolvable in Chapter 17 when we look at error handling in the
Spring MVC library.
Application Events
Another feature of the ApplicationContext not present in the BeanFactory is the ability to publish and
receive events using the ApplicationContext as a broker. In this section we will take a look at its usage.
Search WWH :
