アノテーションインターフェース Bean

メソッドが Spring コンテナーによって管理される Bean を生成することを示します。

概要

このアノテーションの属性の名前とセマンティクスは、意図的に Spring XML スキーマの <bean/> 要素の名前とセマンティクスに似ています。例：

@Bean
public MyBean myBean() {
    // instantiate and configure MyBean obj
    return obj;
}

Bean 名

name() 属性は利用可能ですが、Bean の名前を決定するデフォルトの戦略は、@Bean メソッドの名前を使用することです。このデフォルトは、ConfigurationBeanNameGenerator を設定することで上書きできます。たとえば、完全修飾名の場合は FullyQualifiedConfigurationBeanNameGenerator を設定します。個々の Bean に明示的な名前を付けたい場合は、name 属性（またはそのエイリアス value()）を使用できます。また、name は文字列の配列を受け入れるため、1 つの Bean に対して複数の名前（つまり、プライマリ Bean 名と 1 つ以上のエイリアス）を指定できます。

@Bean({"b1", "b2"}) // bean available as 'b1' and 'b2', but not 'myBean'
public MyBean myBean() {
    // instantiate and configure MyBean obj
    return obj;
}

プロファイル、スコープ、レイジー、DependsOn、プライマリ、フォールバック、オーダー

@Bean アノテーションは、profile、scope、lazy、depends-on、primary の属性を提供しないことに注意してください。これらのセマンティクスを宣言するには、@Scope、@Lazy、@DependsOn、@Primary アノテーションと組み合わせて使用する必要があります。例:

@Bean
@Profile("production")
@Scope("prototype")
public MyBean myBean() {
    // instantiate and configure MyBean obj
    return obj;
}

前述のアノテーションの意味は、コンポーネントクラスレベルでの使用方法と一致します。@Profile は、特定の Bean を選択的に含めることを可能にします。@Scope は、Bean のスコープをシングルトンから指定されたスコープに変更します。@Lazy は、デフォルトのシングルトンスコープの場合にのみ実際に効果があります。@DependsOn は、この Bean が作成される前に特定の他の Bean の作成を強制します。これは、直接参照によって Bean が表現した依存関係に加えて、通常、シングルトンの起動に役立ちます。@Primary は、単一のターゲットコンポーネントを注入する必要があるが、複数の Bean が型で一致する場合に、インジェクションポイントレベルでの曖昧さを解消するメカニズムです。@Fallback は、このようなシナリオで Bean をフォールバック候補としてマークします。一致する複数の候補のうち 1 つを除くすべての Bean がフォールバックとしてマークされている場合、残りの Bean が選択されます。

さらに、@Bean メソッドは、対応するコンポーネントクラスの対応するアノテーションと同様にインジェクションポイントの解決時に考慮される修飾子アノテーションと @Order 値も宣言できますが、Bean 定義ごとに非常に個別になる可能性があります（同じ Bean クラスの複数の定義の場合））。修飾子は、最初の型の一致後に候補のセットを絞り込みます。順序値は、コレクションインジェクションポイントの場合に解決される要素の順序を決定します（複数のターゲット Bean が型と修飾子で一致する）。

注意 : @Order の値はインジェクションポイントでの優先順位に影響を与える可能性がありますが、上記で記述されていたように、依存関連と @DependsOn 宣言によって決定される独立した問題であるシングルトンの起動順序には影響しないことにご注意ください。また、Priority はメソッドに宣言できないため、このレベルでは使用できません。そのセマンティクスは、型ごとに 1 つの Bean で、@Order 値と @Primary または @Fallback を組み合わせてモデル化できます。

 @Configuration クラスの @Bean メソッド

通常、@Bean メソッドは @Configuration クラス内で宣言されます。この場合、Bean メソッドは、 直接呼び出すことにより、同じクラス内の他の @Bean メソッドを参照できます。これにより、Bean 間の参照が厳密に型指定され、ナビゲート可能になります。このようないわゆる「Bean 間の参照」は、getBean() ルックアップと同様に、スコープと AOP セマンティクスを考慮することが保証されています。これらは、元の "Spring JavaConfig" プロジェクトで知られているセマンティクスであり、実行時にそのような各構成クラスの CGLIB サブクラス化を必要とします。そのため、このモードでは、@Configuration クラスとそのファクトリメソッドを final または private としてマークしないでください。例：

@Configuration
public class AppConfig {

   @Bean
   public FooService fooService() {
       return new FooService(fooRepository());
   }

   @Bean
   public FooRepository fooRepository() {
       return new JdbcFooRepository(dataSource());
   }

   // ...
}

@Bean Lite モード

@Bean メソッドは、@Configuration アノテーションが付けられていないクラス内で宣言することもできます。Bean メソッドが @Configuration アノテーションが付けられていない Bean 上で宣言されている場合、そのメソッドはいわゆる「ライト」モードで処理されます。

ライトモードの Bean メソッドは、スコーピングおよびライフサイクルコールバックが適切に適用された状態で、コンテナー（XML の factory-method 宣言と同様）によってプレーンファクトリメソッドとして扱われます。この場合、包含クラスは変更されないままであり、包含クラスまたはファクトリメソッドに対する異常な制約はありません。

@Configuration クラスの Bean メソッドのセマンティクスとは異なり、ライトモードでは「Bean 間参照」はサポートされていません。代わりに、1 つの @Bean メソッドがライトモードで別の @Bean メソッドを呼び出す場合、呼び出しは標準の Java メソッド呼び出しです。Spring は、CGLIB プロキシを介した呼び出しをインターセプトしません。これは、@Transactional メソッド間呼び出しと類似しており、プロキシモードでは、Spring は呼び出しをインターセプトしません。Spring は、AspectJ モードでのみインターセプトします。

例:

@Component
public class Calculator {
   public int sum(int a, int b) {
       return a+b;
   }

   @Bean
   public MyBean myBean() {
       return new MyBean();
   }
}

ブートストラップ

AnnotationConfigApplicationContext などを使用してコンテナーをブートストラップする方法など、詳細については @Configuration の Javadoc を参照してください。

 @Bean メソッドを返す BeanFactoryPostProcessor 

Spring BeanFactoryPostProcessor（BFPP）型を返す @Bean メソッドについては、特別な考慮が必要です。BFPP オブジェクトは、コンテナーのライフサイクルの非常に早い段階でインスタンス化する必要があるため、@Configuration クラス内の @Autowired、@Value、@PostConstruct などのアノテーションの処理を妨げる可能性があります。これらのライフサイクルの課題を回避するには、@Bean メソッドを返す BFPP を static としてマークします。例：

@Bean
public static PropertySourcesPlaceholderConfigurer pspc() {
    // instantiate, configure and return pspc ...
}

このメソッドを static とマークすることで、宣言元の @Configuration クラスのインスタンス化を起こさずに呼び出すことができ、前述のライフサイクル競合を回避できます。ただし、static @Bean メソッドは、前述のようにスコープと AOP セマンティクスに関して拡張されないことに注意してください。これは、通常他の @Bean メソッドから参照されない BFPP の場合には課題ありません。念のため、戻り値の型が BeanFactoryPostProcessor に割り当てられる非静的 @Bean メソッドについては、INFO レベルのログメッセージが発行されます。

 @Bean メソッドを返す BeanPostProcessor 

同様に、Spring BeanPostProcessor (BPP) 型を返す @Bean メソッドについても特別な配慮が必要です。BPP オブジェクトはコンテナーのライフサイクルの早い段階でインスタンス化する必要があるため、BPP を返す非静的 @Bean メソッドは、宣言元の @Configuration クラスの早期初期化を引き起こし、@Configuration クラス内の他の Bean (およびそれらの Bean の依存関係) が完全な後処理の対象外になる可能性があります。これらのライフサイクルの課題を回避するには、@Bean メソッドを返す BPP を static としてマークします。例:

@Bean
public static MyBeanPostProcessor myBeanPostProcessor() {
    return new MyBeanPostProcessor();
}

このメソッドを static としてマークすることで、宣言元の @Configuration クラスのインスタンス化を起こさずに呼び出すことができます。さらに、コンテナーがポストプロセッサーを作成するために他の Bean をインスタンス化する必要がないように、メソッドは依存関係を宣言しないことが理想的です。他の Bean をインスタンス化すると、それらの Bean もポスト処理の対象外となるためです。このような Bean については、次のような WARN レベルのログメッセージが表示されるはずです。「型 [org.example.SomeType] の Bean 'someBean' は、すべての BeanPostProcessors による処理の対象外です (例: 自動プロキシの対象外)」。