🏇 🧖🏾 🧚🏾 春の内側。コンテキストの初期化手順 📔 👒 🧑🏾‍🤝‍🧑🏻

親愛なるハブラフ人の皆さん、こんにちは。 3年間、Springを使用するプロジェクトに取り組んできました。私はいつもそれがどのように内部に配置されているかを理解することに興味がありました。 Springの内部構造に関する記事を検索しましたが、残念ながら何も見つかりませんでした。

Springの内部構造に興味がある人は誰でも猫をお願いします。

この図は、ApplicationContextを上げる主な段階を示しています。この投稿では、これらの各段階に焦点を当てます。いくつかの段階を詳細に検討し、いくつかの段階を一般的な用語で説明します。

1.設定の解析とBeanDefinitionの作成

春の4番目のバージョンのリリース後、コンテキストを構成する4つの方法があります。

XML構成-ClassPathXmlApplicationContext（「context.xml」）
スキャンするパッケージを示す注釈による構成-AnnotationConfigApplicationContext（“ package.name”）
アノテーション@Configuration -AnnotationConfigApplicationContext（JavaConfig.class）でマークされたクラス（またはクラスの配列）を示すアノテーションを介した構成。この構成方法はJavaConfigと呼ばれます。
Groovy構成-GenericGroovyApplicationContext（「context.groovy」）

4つすべての方法は、ここで非常によく書かれています。

最初の段階の目標は、すべてのBeanDefinitionを作成することです。 BeanDefinitionは、将来のBeanのメタデータにアクセスできる特別なインターフェースです。使用している構成に応じて、1つまたは別の構成解析メカニズムが使用されます。

XML設定

Xml構成の場合、 BeanDefinitionReaderインターフェースを実装するクラスXmlBeanDefinitionReaderが使用されます。ここではすべてが透明です。 XmlBeanDefinitionReaderはInputStreamを受け取り、 DefaultDocumentLoaderを介してドキュメントをロードします。次に、ドキュメントの各要素が処理され、それがビンの場合、入力されたデータ（id、name、class、alias、init-method、destroy-methodなど）に基づいてBeanDefinitionが作成されます。各BeanDefinitionはマップに配置されます。マップはDefaultListableBeanFactoryクラスに保存されます。コードでは、Mapは次のようになります。

/** Map of bean definition objects, keyed by bean name */ private final Map<String, BeanDefinition> beanDefinitionMap = new ConcurrentHashMap<String, BeanDefinition>(64);

スキャンまたはJavaConfigのパッケージを示す注釈による構成

スキャンまたはJavaConfigのパッケージを示す注釈による構成は、xmlによる構成とは根本的に異なります。どちらの場合も、 AnnotationConfigApplicationContextクラスが使用されます。

 new AnnotationConfigApplicationContext(JavaConfig.class);

または

 new AnnotationConfigApplicationContext(“package.name”);

AnnotationConfigApplicationContextの内部を見ると、2つのフィールドが表示されます。

 private final AnnotatedBeanDefinitionReader reader; private final ClassPathBeanDefinitionScanner scanner;

ClassPathBeanDefinitionScannerは、指定されたパッケージをスキャンして、 @ Componentアノテーション（または@Componentを含むその他のアノテーション）でマークされたクラスを探します。見つかったクラスが解析され、BeanDefinitionが作成されます。

スキャンを実行するには、スキャン用のパッケージを構成で指定する必要があります。

 @ComponentScan({"package.name"})

または

 <context:component-scan base-package="package.name"/>

AnnotatedBeanDefinitionReaderはいくつかのステップで機能します。

最初のステップは、さらに解析するためにすべての@Configurationを登録することです。構成で条件が使用されている場合、 条件が trueを返す構成のみが登録されます。 条件付き注釈は、春の4番目のバージョンに登場しました。コンテキストを上げるときに、ビン/構成を作成するかどうかを決定する必要がある場合に使用されます。また、決定は特別なクラスによって行われ、 Conditionインターフェースを実装する必要があります。
2番目のステップは、特別なBeanFactoryPostProcessor 、つまりBeanDefinitionRegistryPostProcessorを登録することです。これは、 ConfigurationClassParserクラスを使用して、JavaConfigを解析し、 BeanDefinitionを作成します。

Groovyの構成

この構成は、ファイルがXMLではなくGroovyであることを除いて、Xmlを介した構成と非常に似ています。 GroovyBeanDefinitionReaderクラスは、groovy構成の読み取りと解析を処理します。

2.作成されたBeanDefinitionを構成する

最初の段階の後、 BeanDefinitionを格納するマップがあります。 Springアーキテクチャは、Beanが実際に作成される前に、そのBeanに影響を与えることができるように構築されています。つまり、クラスメタデータにアクセスできます。これを行うために、特別なインターフェースBeanFactoryPostProcessorがあり 、これを実装して、作成されたBeanDefinitionにアクセスし、それらを変更できます。このインターフェースにはメソッドが1つしかありません。

 public interface BeanFactoryPostProcessor { void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException; }

postProcessBeanFactoryメソッドは、 ConfigurableListableBeanFactoryパラメーターを受け入れます。このファクトリには、すべてのBeanDefinitionNamesを取得し、特定の名前の特定のメタデータのBeanDefinitionを取得するgetBeanDefinitionNamesを含む多くの便利なメソッドが含まれています。

BeanFactoryPostProcessorインターフェースのネイティブ実装の1つを見てみましょう。通常、データベースに接続するための設定は別のプロパティファイルに転送され、 PropertySourcesPlaceholderConfigurerを使用して読み込まれ、これらの値を目的のフィールドに挿入します。注入はキーによって行われるため、Beanのインスタンスを作成する前に、このキーをプロパティファイルの値自体に置き換える必要があります。この置換は、 BeanFactoryPostProcessorインターフェースを実装するクラスで発生します。このクラスの名前はPropertySourcesPlaceholderConfigurerです。プロセス全体を下の図に示します。

ここで何が起こっているのかもう一度見てみましょう。 ClassNameクラスのBeanDefinitionがあります。クラスコードを以下に示します。

 @Component public class ClassName { @Value("${host}") private String host; @Value("${user}") private String user; @Value("${password}") private String password; @Value("${port}") private Integer port; }

PropertySourcesPlaceholderConfigurerがこのBeanDefinitionを処理しない場合、ClassNameのインスタンスを作成した後、値「$ {host}」がホストフィールドに注入されます（対応する値が残りのフィールドに注入されます）。 PropertySourcesPlaceholderConfigurerが引き続きこのBeanDefinitionを処理する場合、処理後、このクラスのメタデータは次のようになります。

 @Component public class ClassName { @Value("127.0.0.1") private String host; @Value("root") private String user; @Value("root") private String password; @Value("27017") private Integer port; }

したがって、これらのフィールドには正しい値が挿入されます。

作成されたBeanDefinitionの設定ループにPropertySourcesPlaceholderConfigurerを追加するには、次のいずれかを実行する必要があります。

XML構成用。

 <context:property-placeholder location="property.properties" />

JavaConfigの場合。

 @Configuration @PropertySource("classpath:property.properties") public class DevConfig { @Bean public static PropertySourcesPlaceholderConfigurer configurer() { return new PropertySourcesPlaceholderConfigurer(); } }

PropertySourcesPlaceholderConfigurerは静的として宣言する必要があります。静的でない場合、 @ Configurationクラス内で@ Valueを使用しようとするまで、すべてが機能します。

3.カスタムFactoryBeanの作成

FactoryBeanは、タイプBeanの作成プロセスを委任できる汎用インターフェースです。構成がxmlのみであった当時、開発者はBeanの作成プロセスを制御できるメカニズムを必要としていました。これがまさにこのインターフェースの目的です。問題をよりよく理解するために、XML構成の例を示します。

 <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd"> <bean id="redColor" scope="prototype" class="java.awt.Color"> <constructor-arg name="r" value="255" /> <constructor-arg name="g" value="0" /> <constructor-arg name="b" value="0" /> </bean> </beans>

一見、すべてが正常であり、問題はありません。しかし、別の色が必要な場合はどうでしょうか？別のBeanを作成しますか？質問なし。

 <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd"> <bean id="redColor" scope="prototype" class="java.awt.Color"> <constructor-arg name="r" value="255" /> <constructor-arg name="g" value="0" /> <constructor-arg name="b" value="0" /> </bean> <bean id="green" scope="prototype" class="java.awt.Color"> <constructor-arg name="r" value="0" /> <constructor-arg name="g" value="255" /> <constructor-arg name="b" value="0" /> </bean> </beans>

しかし、毎回ランダムな色が必要な場合はどうでしょうかこれがFactoryBeanインターフェースの助けとなります。

すべてのタイプBean- Colorの作成を担当するファクトリーを作成しましょう。

 package com.malahov.factorybean; import org.springframework.beans.factory.FactoryBean; import org.springframework.stereotype.Component; import java.awt.*; import java.util.Random; /** * User: malahov * Date: 18.04.14 * Time: 15:59 */ public class ColorFactory implements FactoryBean<Color> { @Override public Color getObject() throws Exception { Random random = new Random(); Color color = new Color(random.nextInt(255), random.nextInt(255), random.nextInt(255)); return color; } @Override public Class<?> getObjectType() { return Color.class; } @Override public boolean isSingleton() { return false; } }

それをxmlに追加し、以前に宣言したタイプbeans- Colorを削除します。

 <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd"> <bean id="colorFactory" class="com.malahov.temp.ColorFactory"></bean> </beans>

これで、 Color.class型のBeanの作成はColorFactoryによって委任され、新しいBeanが作成されるたびにgetObjectメソッドが使用されます。

JavaConfigを使用するユーザーにとって、このインターフェースはまったく役に立ちません。

4. Beanインスタンスの作成

BeanFactoryはBeanのインスタンスを作成し、必要に応じてこれをカスタムFactoryBeanに委任します。 Beanインスタンスは、以前に作成されたBeanDefinitionに基づいて作成されます。

5.作成されたBeanのセットアップ

BeanPostProcessorインターフェースを使用すると、Beanがコンテナに入る前に、設定プロセスに侵入することができます。インターフェイスにはいくつかのメソッドがあります。

 public interface BeanPostProcessor { Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException; Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException; }

ビンごとに両方のメソッドが呼び出されます。どちらのメソッドにもまったく同じパラメーターがあります。唯一の違いは、それらが呼び出される順序です。最初のメソッドはinitメソッドの前に呼び出され、2番目のメソッドはその後に呼び出されます。この段階で、Beanインスタンスはすでに作成されており、再構成されていることを理解することが重要です。 2つの重要なポイントがあります。

両方のメソッドは最終的にBeanを返す必要があります。メソッドでnullを返す場合、コンテキストからこのビンを受け取るとnullになります。すべてのビンはbinpostprocessorを通過するため、コンテキストを上げた後、ビンをリクエストすると、nullの意味でfigsを受け取ります。
オブジェクトにプロキシを作成する場合は、initメソッドを呼び出した後にこれを行うのが一般的であることに注意してください。つまり、 postProcessAfterInitializationメソッドでこれを行う必要があります。

チューニングプロセスを次の図に示します。 BeanPostProcessorが呼び出される順序は不明ですが、それらが順番に実行されることは確かです。

これが何のためであるかをよりよく理解するために、例を見てみましょう。

大規模プロジェクトを開発する場合、原則として、チームはいくつかのグループに分割されます。たとえば、開発者の最初のグループはプロジェクトのインフラストラクチャを記述しており、2番目のグループは最初のグループの成果を使用してビジネスロジックを記述しています。 2番目のグループが、いくつかの値（たとえば乱数）をビンに挿入できる機能を必要としているとします。

最初の段階で、値を挿入する必要があるクラスのフィールドをマークする注釈が作成されます。

 @Retention(RetentionPolicy.RUNTIME) @Target(ElementType.FIELD) public @interface InjectRandomInt { int min() default 0; int max() default 10; }

デフォルトでは、乱数の範囲は0〜10です。

次に、このアノテーションのハンドラー、つまり、 InjectRandomIntアノテーションを処理するBeanPostProcessor実装を作成する必要があります。

 @Component public class InjectRandomIntBeanPostProcessor implements BeanPostProcessor { private static final Logger LOGGER = LoggerFactory.getLogger(InjectRandomIntBeanPostProcessor.class); @Override public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException { LOGGER.info("postProcessBeforeInitialization::beanName = {}, beanClass = {}", beanName, bean.getClass().getSimpleName()); Field[] fields = bean.getClass().getDeclaredFields(); for (Field field : fields) { if (field.isAnnotationPresent(InjectRandomInt.class)) { field.setAccessible(true); InjectRandomInt annotation = field.getAnnotation(InjectRandomInt.class); ReflectionUtils.setField(field, bean, getRandomIntInRange(annotation.min(), annotation.max())); } } return bean; } @Override public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException { return bean; } private int getRandomIntInRange(int min, int max) { return min + (int)(Math.random() * ((max - min) + 1)); } }

このBeanPostProcessorのコードは非常に透過的であるため、ここでは詳しく説明しませんが、重要な点が1つあります。

BeanPostProcessorはBeanでなければならないため、 @ Componentアノテーションでマークするか、通常のBeanとしてxml構成に登録します。

開発者の最初のグループはそのタスクを完了しました。これで、2番目のグループはこれらの開発を使用できます。

 @Component @Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE) public class MyBean { @InjectRandomInt private int value1; @InjectRandomInt(min = 100, max = 200) private int value2; private int value3; @Override public String toString() { return "MyBean{" + "value1=" + value1 + ", value2=" + value2 + ", value3=" + value3 + '}'; } }

その結果、コンテキストから取得されたタイプMyBeanのすべてのビンは、すでに初期化されたフィールドvalue1およびvalue2で作成されます。また、これらのフィールドに値を挿入する段階は、ビンがどのような@スコープを持っているかに依存することに注意してください。 SCOPE_SINGLETON-初期化は、コンテキストを上げる段階で1回発生します。 SCOPE_PROTOTYPE-リクエストに応じて毎回初期化が実行されます。 2番目の場合、BeanはすべてのBeanPostProcessorsを通過するため、パフォーマンスに大きな影響を与える可能性があります。

完全なプログラムコードはこちらにあります。

EvgenyBorisovに特に感謝します。彼のコースのおかげで、私はこの投稿を書くことにしました。

また、JPoint 2014からの彼のレポートを見ることをお勧めします。

春の内側。 コンテキストの初期化手順