1.13。環境抽象
Environmentインタフェースは、コンテナ抽象的に統合されたアプリケーション環境の二つの重要な側面をモデルにすることができますprofileとproperties。
profileのみ与えられているプロファイルは、ビーンが唯一の論理的グループで定義された名前付けコンテナをアクティブに登録されています。ビーンは、XMLで定義されたか、注釈付きのどちらか、プロファイルに割り当てることができます。環境関連オブジェクトプロファイルの役割は、現在のプロファイルが（もしあれば）がアクティブであり、アクティブでなければならない（もしあれば）デフォルトプロファイルの場合かを決定することです。
プロパティが重要な役割のほぼすべてのアプリケーションで再生し、さまざまなソースに由来することができる：プロパティファイル、JVMのシステムプロパティ、システム環境変数、JNDI、サーブレットコンテキストパラメータ、プロパティ、オブジェクト、マップオブジェクト。環境関連のオブジェクトと役割は、ユーザーが構成プロパティ用の便利なサービス・インターフェースを提供することであり、ソースプロパティを解析する属性。
1.13.1。ビーンは、プロファイルを定義しました
使用@Profile
プロファイル文字列は、単純なプロファイル名（例えば、生産）または発現プロファイルを含めることができます。発現プロファイルは、より複雑な発現プロファイルロジック（例えば、を可能にしますproduction & us-east）。これは、次の演算子発現プロファイルをサポートしています。
!：いいえロジック&：ロジックと|：論理または
演算子を|あなたは＆や括弧を使用せずに混在させることはできません。例えば、production & us-east | eu-centralそうではありません有効な式。それは次のように表現されなければなりませんproduction & (us-east | eu-central)。
あなたは可能な@Profileカスタムの組み合わせのコメントを作成するにはメタアノテーションとして使用します。次の例では、カスタム定義@Productionあなたはとしてそれを使用することができ、注釈を@Profile("production")代替：
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Profile("production")
public @interface Production {
}場合は@Profileラベルされた@Configurationクラスを一つ以上の指定されたプロファイルがアクティブでない限り、それ以外の場合は、クラスに関連付けられているすべて無視されます@Beanメソッドと@Importのコメントを。場合@Componentや@Configurationカテゴリがでマークされ@Profile({"p1", "p2"})、アクティブ化プロファイル「P1」または「P2」がない限り、クラスが登録されたか、他の方法で処理されていません。NOT演算子（に与えられたプロファイルがあれば!）前置された登録プロファイルが要素を注釈付きのときにのみ活性化されません。例えば、所与の@Profile({"p1", "!p2"})プロファイル「P1」は、アクティブまたはプロファイル「P2」がアクティブでない場合、それが登録されます。
@Profileも豆の唯一の特定のクラスを含むように、メソッドレベルの構成で宣言すること
@Profileを使用する場合@Bean方法、特別な状況が生じ得る：（オーバーロードコンストラクタと同様）ヘビーデューティー@Bean方法Javaメソッドについては同じ名前を持つ、プロファイル@全てDECLAREオーバーロードされたメソッドの条件にわたって一貫する必要があります。条件が一致していない場合は、条件文の中で唯一のオーバーロードされたメソッドは非常に重要です。したがって、プロファイル@オーバーロードされたメソッドは、特定のパラメータの署名を選択するために使用することができません。作成する場合、同じビーンファクトリメソッドとの間で解析すると、すべてのスプリングコンストラクタ解決アルゴリズムに従います。
代替豆条件を定義する異なるプロファイルを使用するように、これらの名前は、前の例のように、同じ属性@Bean名Bean名を参照して使用することにより、異なるJavaメソッド名を使用してください。パラメータは、最初の有効なJavaクラスであり、同じシグネチャ（例えば、全ての変異体は全く基準ファクトリメソッドを持たない）、ある場合（のみ特定のメソッド名と署名のパラメータとして）この構成の唯一の方法を表します。
XML Bean定義プロファイル
XMLは、対応するエントリのある<beans>要素profileの属性。
XMLは、上記の対応する用語の発現プロファイルをサポートしていません。しかし、使用して!オペレーター・プロファイルをキャンセルします。あなたは論理「と」次の例で示すように、ネストされたプロファイルを適用することができます。
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:jdbc="http://www.springframework.org/schema/jdbc"
xmlns:jee="http://www.springframework.org/schema/jee"
xsi:schemaLocation="...">
<!-- other bean definitions -->
<beans profile="production">
<beans profile="us-east">
<jee:jndi-lookup id="dataSource" jndi-name="java:comp/env/jdbc/datasource"/>
</beans>
</beans>
</beans>生産および米国イーストプロファイルがアクティブである場合、前の例では、データソース豆が開示されています。
活性化プロフィール
最も直接的な方法は、ApplicationContextの環境APIを介してプログラム的に設定するためです。
AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext();
ctx.getEnvironment().setActiveProfiles("development");
ctx.register(SomeConfig.class, StandaloneDataConfig.class, JndiDataConfig.class);
ctx.refresh();あなたもできspring.profiles.active宣言プロファイル属性は、システム環境変数プロファイルによって指定されたweb.xml JNDIのエントリとして、JVMシステム・プロパティ、またはサーブレットコンテキストパラメータかもしれ有効にします。統合テストでは、あなたが使用することができspring-test、モジュールを@ActiveProfiles活性プロフィールのコメントを宣言します。
あなたは、いくつかのプロファイルをアクティブにすることができます。あなたはするようにプログラムすることができるsetActiveProfiles()方法の複数のプロファイル名を提供します
ctx.getEnvironment().setActiveProfiles("profile1", "profile2");
宣言的、spring.profiles.activeあなたは、プロファイル名のカンマ区切りリストを受け入れることができます
-Dspring.profiles.active="profile1,profile2"
デフォルトのプロフィール
デフォルトのプロファイルがありますdefault。
あなたは渡すことができますEnvironment上のsetDefaultProfiles()プロファイルの、またはを使用してデフォルト名を変更するspring.profiles.defaultプロパティ。
1.13.2。PropertySource抽象
Springの環境抽象化は、構成属性階層ソース検索操作を提供します。
ApplicationContext ctx = new GenericApplicationContext();
Environment env = ctx.getEnvironment();
boolean containsMyProperty = env.containsProperty("my-property");
System.out.println("Does my environment contain the 'my-property' property? " + containsMyProperty);上記のコードスニペットでは、春には、現在の環境のための高度な方法の私の-property属性の定義かどうかを尋ねご覧ください。この質問に答えるためには、Environmentグループ内のオブジェクトPropertySourceの対象に検索を実行します。PropertySource任意のキーである-簡単な要約値のソース、StandardEnvironment PropertySourceの春は、属性セットJVMシステム（表し、2つのオブジェクトを配置System.getProperties()）、システム環境変数のセット（の担当者System.getenv()）。
これらのデフォルトは、別のアプリケーションで使用するため、StandardEnvironment源の存在下での属性。StandardServletEnvironmentは（サーブレット設定およびサーブレット・コンテキスト・パラメータを含む）は、デフォルトのプロパティ他のソースを充填しました。これは、選択的JndiPropertySourceを有効にすることができます。
あなたがStandardEnvironmentを使用するときのために具体的に、私の財産システム、プロパティまたは私の財産、環境変数は、実行時に存在しているenv.containsProperty("my-property")呼び出しがtrueを返します。
実行される検索は階層的です。デフォルトでは、システムプロパティには、環境変数よりも優先されます。同時に2つの場所での通話中に自分の財産を設定している場合ので、env.getProperty("my-property")プロパティ、プロパティの値を、システムが「勝つ」と復帰します。プロパティ値が合併しないことに注意しますが、完全に以前のエントリでカバーされますしてください。
共通StandardServletEnvironmentについては、次の階層、一番上の優先順位が最も高いエントリを完了します。
ServletConfigパラメータ（該当する場合、例えば、DispatcherServletのコンテキストの場合）ServletContextパラメータ（web.xmlのコンテキストパラメータエントリ）- JNDI環境変数（で、java：comp / env /エントリ）
- JVMシステム特性（-dコマンドラインパラメータ）
- JVMシステム環境（オペレーティングシステム環境変数）
最も重要なのは、全体のメカニズムが設定可能です。たぶん、あなたは、この検索にカスタム属性のソースを統合したいです。これを行うには、実現し、自身のPropertySource PropertySourcesをインスタンスをインスタンス化し、現在の環境でのコレクションに追加します。これを行う方法を次の例が示します：
ConfigurableApplicationContext ctx = new GenericApplicationContext();
MutablePropertySources sources = ctx.getEnvironment().getPropertySources();
sources.addFirst(new MyPropertySource());前のコードでは、MyPropertySourceは検索で最高の優先度に追加されました。それは私の-property属性が含まれている場合は、属性が検出され、リターンは他のPropertySourceの私の-property属性をサポートします。MutablePropertySourcesAPIは、ソース属性セットの正確な操作を可能とする、多くの方法が開示されています。
1.13.3。使用@PropertySource
@PropertySourceアノテーションメカニズムは、追加の利便性を提供するとSpring環境にPropertySourceを宣言しました。
@PropertySource（ "クラスパス：/com/myco/app.properties"）
@PropertySourceすべての存在下でのリソースの位置${..}のプレースホルダは、ソースの属性のセットに基づいています解決するために、環境に対して登録されています
@PropertySource("classpath:/com/${my.placeholder:default/path}/app.properties")
プレースホルダの解決次に、登録属性（例えば、属性またはシステム環境変数）のいずれかでmy.placeholderソース存在を適切な値に仮定する。そうでない場合は、default/pathデフォルトとして使用します。デフォルトが指定されていないと、属性を解決できない場合にスローされますIllegalArgumentException。
@PropertySourceコメントは、Javaの規則8によると、繰り返し可能です。しかし、そのようなすべての@PropertySource注釈は、あなたが直接クラス宣言で設定することができます。または、同じコメントで元に対して宣言注釈をカスタマイズすることができ、同じレベルで宣言する必要があります。直接のコメントは効果的に元のノートをカバーしますので、直接コメントやメタデータアノテーションの混合使用を推奨しません。
1.13.4。プレースホルダを解析ステートメント
歴史的には、プレースホルダ値の要素は、JVMシステムプロパティまたは環境変数に応じて解決することができます。これはもはやケースです。環境抽象化を容器全体に統合されているので、それを通るルート解像度プレースホルダに簡単です。あなたが好きなように解決プロセスを構成することができますことをこれが意味。あなたは、検索システムプロパティと環境変数の優先順位を変更することができ、それはまた、それらを完全に削除することができます。ミックスソース属性する必要があればまた、あなた自身を追加することができます。
具体的には、かかわらず、顧客は属性が定義された場所に、次の文は、長い環境で利用可能なプロパティとしてとして有効です。
<beans>
<import resource="com/bank/service/${customer}-config.xml"/>
</beans>1.14。LoadTimeWeaverを登録
ときLoadTimeWeaver時のクラスは、Java仮想マシン（JVM）内にロードされ、春には、動的なクラスを変換するために使用されます。
ロード時ウィービングを有効にするには、それが可能な@EnableLoadTimeWeavingあなたの1に追加し@Configuration、次の例のように、クラス：
@Configuration
@EnableLoadTimeWeaving
public class AppConfig {
}また、XML構成は、あなたが使用できるcontext:load-time-weaver要素を：
<beans>
<context:load-time-weaver/>
</beans>一度のためApplicationContextに構成される、ApplicationContextの任意の豆を実現することができるLoadTimeWeaverAware基準ローディング織らインスタンスを受信するようになっています。SpringのJPAサポートと組み合わせて使用する場合、この機能は織りがJPAクラスの変換時にロードする必要があるかもしれないときので、特に便利です。