使用例

キー / 値ペア testbean.name=myTestBean を含むファイル app.properties を指定すると、次の @Configuration クラスは @PropertySource を使用して app.properties を Environment の PropertySources のセットに提供します。

 @Configuration
 @PropertySource("classpath:/com/myco/app.properties")
 public class AppConfig {

     @Autowired
     Environment env;

     @Bean
     public TestBean testBean() {
         TestBean testBean = new TestBean();
         testBean.setName(env.getProperty("testbean.name"));
         return testBean;
     }
 }

Environment オブジェクトは構成クラスに @Autowired として追加され、TestBean オブジェクトを設定するときに使用されることに注意してください。上記の構成では、testBean.getName() を呼び出すと "myTestBean" が返されます。

<bean> および @Value アノテーションの ${...} プレースホルダーの解決

PropertySource のプロパティを使用して <bean> 定義または @Value アノテーションの ${...} プレースホルダーを解決するには、適切なエンベディッドバリューリゾルバーが ApplicationContext で使用される BeanFactory に登録されていることを確認する必要があります。これは、XML で <context:property-placeholder> を使用すると自動的に発生します。@Configuration クラスを使用する場合、これは、static @Bean メソッドを介して PropertySourcesPlaceholderConfigurer を明示的に登録することで実現できます。ただし、static @Bean メソッドを介した PropertySourcesPlaceholderConfigurer の明示的な登録は、通常、プレースホルダー構文などの設定をカスタマイズする必要がある場合にのみ必要であることに注意してください。@Configuration の javadoc の「外部化された値の操作」セクションおよび「 詳細と例については、@Bean の javadoc の「 @Bean メソッドを返す BeanFactoryPostProcessor」に関する注記を参照してください。

@PropertySource リソースロケーション内の ${...} プレースホルダーの解決

@PropertySource  リソースの場所に存在する ${...} プレースホルダーは、環境に対してすでに登録されているプロパティソースのセットに対して解決されます。例：

 @Configuration
 @PropertySource("classpath:/com/${my.placeholder:default/path}/app.properties")
 public class AppConfig {

     @Autowired
     Environment env;

     @Bean
     public TestBean testBean() {
         TestBean testBean = new TestBean();
         testBean.setName(env.getProperty("testbean.name"));
         return testBean;
     }
 }

"my.placeholder" がすでに登録されているプロパティソースの 1 つに存在すると仮定します。システムプロパティまたは環境変数の場合、プレースホルダーは対応する値に解決されます。そうでない場合は、"default/path" がデフォルトとして使用されます。デフォルト値（コロン ":" で区切られる）の表現はオプションです。デフォルトが指定されておらず、プロパティを解決できない場合、IllegalArgumentException がスローされます。

@PropertySource でオーバーライドするプロパティに関する注意

特定のプロパティキーが複数の .properties ファイルに存在する場合、最後に処理された @PropertySource アノテーションが「勝ち」、オーバーライドします。

例: 2 つのプロパティファイル a.properties および b.properties が与えられた場合、@PropertySource アノテーションで参照する次の 2 つの構成クラスを検討してください。

 @Configuration
 @PropertySource("classpath:/com/myco/a.properties")
 public class ConfigA { }

 @Configuration
 @PropertySource("classpath:/com/myco/b.properties")
 public class ConfigB { }
 

オーバーライドの順序は、これらのクラスがアプリケーションコンテキストに登録される順序によって異なります。

 AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext();
 ctx.register(ConfigA.class);
 ctx.register(ConfigB.class);
 ctx.refresh();
 

上記のシナリオでは、ConfigB が最後に登録されたため、b.properties のプロパティは a.properties に存在する重複をオーバーライドします。

特定の状況では、@PropertySource アノテーションを使用する場合、プロパティソースの順序を厳密に制御することが不可能または実用的でない場合があります。例: 上記の @Configuration クラスがコンポーネントスキャンを介して登録された場合、順序を予測することは困難です。このような場合、およびオーバーライドが重要な場合、ユーザーはプログラムによる PropertySource API の使用にフォールバックすることをお勧めします。詳細については、ConfigurableEnvironment および MutablePropertySources javadoc を参照してください。

注: このアノテーションは、Java 8 規則に従って再現可能です。ただし、このような @PropertySource アノテーションはすべて、同じレベルで宣言する必要があります。構成クラスで直接宣言するか、同じカスタムアノテーション内のメタアノテーションとして宣言する必要があります。直接アノテーションがメタアノテーションを効果的にオーバーライドするため、直接アノテーションとメタアノテーションの混合は推奨されません。