Package org.springframework.context.support

Class AbstractResourceBasedMessageSource

java.lang.Object
org.springframework.context.support.MessageSourceSupport
org.springframework.context.support.AbstractMessageSource
org.springframework.context.support.AbstractResourceBasedMessageSource
All Implemented Interfaces:
HierarchicalMessageSource, MessageSource
Direct Known Subclasses:
ReloadableResourceBundleMessageSource, ResourceBundleMessageSource
public abstract class AbstractResourceBasedMessageSource extends AbstractMessageSource
Abstract base class for MessageSource implementations based on resource bundle conventions, such as ResourceBundleMessageSource and ReloadableResourceBundleMessageSource. Provides common configuration methods and corresponding semantic definitions.
Since:
4.3
Author:
Juergen Hoeller
See Also:

  • Constructor Details

    • AbstractResourceBasedMessageSource

      public AbstractResourceBasedMessageSource()

  • Method Details

    • setBasename

      public void setBasename(String basename)
      Set a single basename, following the basic ResourceBundle convention of not specifying file extension or language codes. The resource location format is up to the specific MessageSource implementation.

      Regular and XMl properties files are supported: for example, "messages" will find a "messages.properties", "messages_en.properties" etc arrangement as well as "messages.xml", "messages_en.xml" etc.

      Parameters:
      basename - the single basename
      See Also:

    • setBasenames

      public void setBasenames(String... basenames)
      Set an array of basenames, each following the basic ResourceBundle convention of not specifying file extension or language codes. The resource location format is up to the specific MessageSource implementation.

      Regular and XMl properties files are supported: for example, "messages" will find a "messages.properties", "messages_en.properties" etc arrangement as well as "messages.xml", "messages_en.xml" etc.

      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: In contrast to addBasenames(java.lang.String...), this replaces existing entries with the given names and can therefore also be used to reset the configuration.

      Parameters:
      basenames - an array of basenames
      See Also:

    • addBasenames

      public void addBasenames(String... basenames)
      Add the specified basenames to the existing basename configuration.

      Note: If a given basename already exists, the position of its entry will remain as in the original set. New entries will be added at the end of the list, to be searched after existing basenames.

      Since:
      4.3
      See Also:

    • getBasenameSet

      public Set<String> getBasenameSet()
      Return this MessageSource's basename set, containing entries in the order of registration.

      Calling code may introspect this set as well as add or remove entries.

      Since:
      4.3
      See Also:

    • setDefaultEncoding

      public void setDefaultEncoding(@Nullable String defaultEncoding)
      Set the default charset to use for parsing properties files. Used if no file-specific charset is specified for a file.

      The effective default is the java.util.Properties default encoding: ISO-8859-1. A null value indicates the platform default encoding.

      Only applies to classic properties files, not to XML files.

      Parameters:
      defaultEncoding - the default charset

    • getDefaultEncoding

      @Nullable protected String getDefaultEncoding()
      Return the default charset to use for parsing properties files, if any.
      Since:
      4.3

    • 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 (for example, "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.

      See Also:

    • isFallbackToSystemLocale

      @Deprecated protected boolean isFallbackToSystemLocale()
      Deprecated.
      as of 5.2.2, in favor of getDefaultLocale()
      Return whether to fall back to the system Locale if no files for a specific Locale have been found.
      Since:
      4.3

    • setDefaultLocale

      public void setDefaultLocale(@Nullable Locale defaultLocale)
      Specify a default Locale to fall back to, as an alternative to falling back to the system Locale.

      Default is to fall back to the system Locale. You may override this with a locally specified default Locale here, or enforce no fallback locale at all through disabling "fallbackToSystemLocale".

      Since:
      5.2.2
      See Also:

    • getDefaultLocale

      @Nullable protected Locale getDefaultLocale()
      Determine a default Locale to fall back to: either a locally specified default Locale or the system Locale, or null for no fallback locale at all.
      Since:
      5.2.2
      See Also:

    • setCacheSeconds

      public void setCacheSeconds(int cacheSeconds)
      Set the number of seconds to cache loaded properties files.
      • Default is "-1", indicating to cache forever (matching the default behavior of java.util.ResourceBundle). Note that this constant follows Spring conventions, not ResourceBundle.Control.getTimeToLive(java.lang.String, java.util.Locale).
      • A positive number will cache loaded properties files for 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. Prefer ReloadableResourceBundleMessageSource over ResourceBundleMessageSource in such a scenario, in combination with a non-classpath location.

    • setCacheMillis

      public void setCacheMillis(long cacheMillis)
      Set the number of milliseconds to cache loaded properties files. Note that it is common to set seconds instead: setCacheSeconds(int).
      • Default is "-1", indicating to cache forever (matching the default behavior of java.util.ResourceBundle). Note that this constant follows Spring conventions, not ResourceBundle.Control.getTimeToLive(java.lang.String, java.util.Locale).
      • A positive number will cache loaded properties files for the given number of milliseconds. 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!
      Since:
      4.3
      See Also:

    • getCacheMillis

      protected long getCacheMillis()
      Return the number of milliseconds to cache loaded properties files.
      Since:
      4.3