パッケージ org.springframework.context.support

クラス AbstractResourceBasedMessageSource

java.lang.ObjectSE
org.springframework.context.support.MessageSourceSupport
org.springframework.context.support.AbstractMessageSource
org.springframework.context.support.AbstractResourceBasedMessageSource
実装されたすべてのインターフェース:
HierarchicalMessageSource, MessageSource
既知の直属サブクラス
ReloadableResourceBundleMessageSource, ResourceBundleMessageSource
public abstract class AbstractResourceBasedMessageSource extends AbstractMessageSource
ResourceBundleMessageSource や ReloadableResourceBundleMessageSource などのリソースバンドル規則に基づく MessageSource 実装の抽象基本クラス。一般的な構成方法と対応するセマンティック定義を提供します。
導入:
4.3
作成者:
Juergen Hoeller
関連事項:

  • コンストラクターの詳細

    • AbstractResourceBasedMessageSource

      public AbstractResourceBasedMessageSource()

  • メソッドの詳細

    • setBasename

      public void setBasename(StringSE basename)
      ファイル拡張子または言語コードを指定しないという基本的な ResourceBundle 規則に従って、単一のベース名を設定します。リソースの場所の形式は、特定の MessageSource 実装までです。

      通常のプロパティファイルと XMl プロパティファイルがサポートされています。"messages" は、"messages.properties"、"messages_en.properties" などの配置と、"messages.xml"、"messages_en.xml" などを検索します。

      パラメーター:
      basename - 単一のベースネーム
      関連事項:

    • setBasenames

      public void setBasenames(StringSE... basenames)
      ファイル名または言語コードを指定しないという基本的な ResourceBundle 規則に従って、ベース名の配列を設定します。リソースの場所の形式は、特定の MessageSource 実装までです。

      通常のプロパティファイルと XMl プロパティファイルがサポートされています。"messages" は、"messages.properties"、"messages_en.properties" などの配置と、"messages.xml"、"messages_en.xml" などを検索します。

      関連するリソースバンドルは、メッセージコードを解決するときに順次チェックされます。順次ルックアップのため、 前のリソースバンドルのメッセージ定義は、後のバンドルのメッセージ定義をオーバーライドすることに注意してください。

      メモ: addBasenames(java.lang.String...) とは対照的に、これは既存のエントリを指定された名前に置き換えます。構成をリセットするためにも使用できます。

      パラメーター:
      basenames - ベース名の配列
      関連事項:

    • addBasenames

      public void addBasenames(StringSE... basenames)
      指定されたベース名を既存のベース名構成に追加します。

      メモ: 指定されたベース名がすでに存在する場合、そのエントリの位置は元のセットのままです。リストの最後に新しいエントリが追加され、既存のベース名の後に検索されます。

      導入:
      4.3
      関連事項:

    • getBasenameSet

      public SetSE<StringSE> getBasenameSet()
      登録順にエントリを含む、この MessageSource のベース名セットを返します。

      コードを呼び出すと、このセットをイントロスペクトしたり、エントリを追加または削除したりできます。

      導入:
      4.3
      関連事項:

    • setDefaultEncoding

      public void setDefaultEncoding(@Nullable StringSE defaultEncoding)
      プロパティファイルの解析に使用するデフォルトの文字セットを設定します。ファイルにファイル固有の文字セットが指定されていない場合に使用されます。

      有効なデフォルトは、java.util.Properties のデフォルトのエンコーディング: ISO-8859-1 です。null 値は、プラットフォームのデフォルトのエンコーディングを示します。

      クラシックプロパティファイルにのみ適用され、XML ファイルには適用されません。

      パラメーター:
      defaultEncoding - デフォルトの文字セット

    • getDefaultEncoding

      @Nullable protected StringSE getDefaultEncoding()
      プロパティファイルの解析に使用するデフォルトの文字セットを返します（ある場合）。
      導入:
      4.3

    • setFallbackToSystemLocale

      public void setFallbackToSystemLocale(boolean fallbackToSystemLocale)
      特定のロケールのファイルが見つからない場合に、システムロケールにフォールバックするかどうかを設定します。デフォルトは "true" です。これがオフになっている場合、フォールバックはデフォルトファイルのみになります（例: ベース名 "messages" の "messages.properties" ）。

      システムロケールにフォールバックするのが java.util.ResourceBundle のデフォルトの動作です。ただし、システムロケールがアプリケーションにまったく関係ないアプリケーションサーバー環境では、これは望ましくないことがよくあります。このようなシナリオでは、このフラグを "false" に設定してください。

      関連事項:

    • isFallbackToSystemLocale

      @DeprecatedSE protected boolean isFallbackToSystemLocale()
      使用すべきではありません。
      5.2.2 現在、getDefaultLocale() を推奨
      特定のロケールのファイルが見つからなかった場合に、システムロケールにフォールバックするかどうかを返します。
      導入:
      4.3

    • setDefaultLocale

      public void setDefaultLocale(@Nullable LocaleSE defaultLocale)
      システムのロケールにフォールバックする代わりに、フォールバックするデフォルトのロケールを指定します。

      デフォルトでは、システムのロケールにフォールバックします。ここでローカルに指定されたデフォルトのロケールでこれをオーバーライドするか、"fallbackToSystemLocale" を無効にすることでフォールバックロケールを強制しないことができます。

      導入:
      5.2.2
      関連事項:

    • getDefaultLocale

      @Nullable protected LocaleSE getDefaultLocale()
      フォールバックするデフォルトのロケールを決定します。ローカルで指定されたデフォルトのロケールまたはシステムのロケール、またはフォールバックロケールがない場合は null のいずれかです。
      導入:
      5.2.2
      関連事項:

    • setCacheSeconds

      public void setCacheSeconds(int cacheSeconds)
      ロードされたプロパティファイルをキャッシュする秒数を設定します。
      • デフォルトは "-1" で、永久にキャッシュすることを示します（java.util.ResourceBundle のデフォルトの動作と一致します）。この定数は ResourceBundle.Control.getTimeToLive(java.lang.String, java.util.Locale)SE ではなく Spring の規則に従っていることに注意してください。
      • 正の数は、指定された秒数の間、ロードされたプロパティファイルをキャッシュします。これは基本的に、リフレッシュチェックの間隔です。リフレッシュ試行では、実際にファイルを再ロードする前に、ファイルの最終変更タイムスタンプを最初に確認することに注意してください。ファイルが変更されない場合、リフレッシュの試行は実際には再ロードされないため、この間隔はかなり低く設定できます。
      • "0" の値は、すべてのメッセージアクセスでファイルの最終変更タイムスタンプをチェックします。 本番環境では使用しないでください。

      ClassLoader によっては、ClassLoader がキャッシュされたバージョンのバンドルファイルを保持する可能性があるため、有効期限が確実に機能しない場合があります。このようなシナリオでは、クラスパス以外の場所と組み合わせて、ResourceBundleMessageSource より ReloadableResourceBundleMessageSource を優先します。

    • setCacheMillis

      public void setCacheMillis(long cacheMillis)
      ロードされたプロパティファイルをキャッシュするミリ秒数を設定します。代わりに秒を設定するのが一般的であることに注意してください: setCacheSeconds(int)。
      • デフォルトは "-1" で、永久にキャッシュすることを示します（java.util.ResourceBundle のデフォルトの動作と一致します）。この定数は ResourceBundle.Control.getTimeToLive(java.lang.String, java.util.Locale)SE ではなく Spring の規則に従っていることに注意してください。
      • 正の数は、指定されたミリ秒数の間、ロードされたプロパティファイルをキャッシュします。これは基本的に、リフレッシュチェックの間隔です。リフレッシュ試行では、実際にファイルを再ロードする前に、ファイルの最終変更タイムスタンプを最初に確認することに注意してください。ファイルが変更されない場合、リフレッシュの試行は実際には再ロードされないため、この間隔はかなり低く設定できます。
      • "0" の値は、すべてのメッセージアクセスでファイルの最終変更タイムスタンプをチェックします。 本番環境では使用しないでください。
      導入:
      4.3
      関連事項:

    • getCacheMillis

      protected long getCacheMillis()
      ロードされたプロパティファイルをキャッシュするミリ秒数を返します。
      導入:
      4.3