MessageSource implementation that
accesses resource bundles using specified basenames. This class relies
on the underlying JDK's ResourceBundle implementation,
in combination with the JDK's standard message parsing provided by
MessageFormat.

This MessageSource caches both the accessed ResourceBundle instances and
the generated MessageFormats for each message. It also implements rendering of
no-arg messages without MessageFormat, as supported by the AbstractMessageSource
base class. The caching provided by this MessageSource is significantly faster
than the built-in caching of the java.util.ResourceBundle class.

Unfortunately, java.util.ResourceBundle caches loaded bundles
forever: Reloading a bundle during VM execution is not possible.
As this MessageSource relies on ResourceBundle, it faces the same limitation.
Consider ReloadableResourceBundleMessageSource for an alternative
that is capable of refreshing the underlying bundle files.

Constructor Detail

ResourceBundleMessageSource

Method Detail

setBasename

Set a single basename, following ResourceBundle conventions:
essentially, a fully-qualified classpath location. If it doesn't contain a
package qualifier (such as org.mypackage), it will be resolved
from the classpath root.

Messages will normally be held in the "/lib" or "/classes" directory of
a web application's WAR structure. They can also be held in jar files on
the class path.

Note that ResourceBundle names are effectively classpath locations: As a
consequence, the JDK's standard ResourceBundle treats dots as package separators.
This means that "test.theme" is effectively equivalent to "test/theme",
just like it is for programmatic java.util.ResourceBundle usage.

setBasenames

Set an array of basenames, each following ResourceBundle
conventions: essentially, a fully-qualified classpath location. If it
doesn't contain a package qualifier (such as org.mypackage),
it will be resolved from the classpath root.

The associated resource bundles will be checked sequentially
when resolving a message code. Note that message definitions in a
previous resource bundle will override ones in a later bundle,
due to the sequential lookup.

Note that ResourceBundle names are effectively classpath locations: As a
consequence, the JDK's standard ResourceBundle treats dots as package separators.
This means that "test.theme" is effectively equivalent to "test/theme",
just like it is for programmatic java.util.ResourceBundle usage.

setFallbackToSystemLocale

public void setFallbackToSystemLocale(boolean fallbackToSystemLocale)

Set whether to fall back to the system Locale if no files for a specific
Locale have been found. Default is "true"; if this is turned off, the only
fallback will be the default file (e.g. "messages.properties" for
basename "messages").

Falling back to the system Locale is the default behavior of
java.util.ResourceBundle. However, this is often not desirable
in an application server environment, where the system Locale is not relevant
to the application at all: Set this flag to "false" in such a scenario.

setCacheSeconds

public void setCacheSeconds(int cacheSeconds)

Set the number of seconds to cache loaded resource bundle files.

Default is "-1", indicating to cache forever.

A positive number will expire resource bundles after the given
number of seconds. This is essentially the interval between refresh checks.
Note that a refresh attempt will first check the last-modified timestamp
of the file before actually reloading it; so if files don't change, this
interval can be set rather low, as refresh attempts will not actually reload.

A value of "0" will check the last-modified timestamp of the file on
every message access. Do not use this in a production environment!

Note that depending on your ClassLoader, expiration might not work reliably
since the ClassLoader may hold on to a cached version of the bundle file.
Consider ReloadableResourceBundleMessageSource in combination
with resource bundle files in a non-classpath location.

NOTE: Only works on JDK 1.6 and higher. Consider using
ReloadableResourceBundleMessageSource for JDK 1.5 support
and more flexibility in terms of the kinds of resources to load from
(in particular from outside of the classpath where expiration works reliably).