Spring知識のまとめ
beanプロパティおよびコンストラクタパラメータ:直接量(基本タイプ、Stringsタイプなど).
要素は、属性またはコンストラクタパラメータの値を文字列で指定します.前述のように、JavaBean PropertyEditorはjavaから文字列を使用する.lang.Stringタイプは、実際のプロパティまたはパラメータタイプに変換されます.
idref要素は、コンテナ内の他のbeanのidをまたは要素に渡すとともに、エラー検証機能を提供するために使用されます.
上記bean定義フラグメントは、(実行時に)以下のフラグメントと完全に同等です.
第1の形式が第2の形式よりも望ましい主な原因は、idrefタグを使用して、コンテナが配置時に参照されたbeanが存在するかどうかを検証できることである.2つ目の方法では、client beanに渡されたtargetName属性値は検証されていません.
参照されたbeanが同じXMLファイル内にあり、beanの名前がbean idである場合、localプロパティを使用します.このプロパティを使用すると、XML解析器がXMLファイルを解析するときに参照されたbeanを検証できます.
次のようになります.
depends−onプロパティは、現在のbeanを初期化する前に、1つ以上のbeanを明示的に初期化するために使用することができる.例えば、クラス内の静的ブロックの初期化が行う場合、例えばデータベース駆動の登録が行われる.複数のbeanへの依存を表す必要がある場合は、「depends-on」で指定した複数のbean名をカンマ、スペース、セミコロンなどで区切ることができます.
ApplicationContextが実装するデフォルトの動作は、起動時にすべてのsingleton beanを事前にインスタンス化することです.アプリケーションContextの初期化時にsingleton beanを事前にインスタンス化したくない場合は、beanを遅延インスタンス化に設定できます.遅延初期化beanは、IoCコンテナが起動時にインスタンス化されるか、または最初に使用されるときにインスタンス化されるかを示す.XMLプロファイルでは、遅延初期化は要素のlazy-initプロパティで制御されます.
XML形式でbeanを構成する場合、要素のautowire-candidateプロパティをfalseに設定し、コンテナが自動アセンブリオブジェクトを検索するときにbeanを考慮しないようにします.
経験によれば、すべてのステータスのあるbeanに対してprototype役割ドメインを使用すべきであり、ステータスのないbeanに対してsingleton役割ドメインを使用すべきである.
Springを実現したInitializingBeanとDisposableBeanの2つのフラグインタフェースのbeanは,初期化と析出時にコンテナが前者のafterPropertiesSet()メソッドと後者のdestroy()メソッドを呼び出す.
InitializingBeanインタフェースの使用を避けるには(コードとSpringを結合するので、インタフェースの使用を奨励しません)、Bean定義で一般的な初期化方法を指定します.すなわち、XMLプロファイルでinit-methodプロパティを指定することで完了します.同様に、DisposableBeanフラグインタフェースの使用を回避します(Springにコードを結合するため、インタフェースの使用を奨励しません).bean定義で一般的なプロファイルメソッドを指定できます.すなわち、XMLプロファイルでdestroy-methodプロパティを指定することで完了します.
最上位レベル要素'default-init-method'属性の出現は、Spring IoCコンテナがbean上の'init'というメソッドを初期化メソッドコールバックとして認識し、beanが作成およびアセンブリされると、beanクラスがこのようなメソッドを有する場合、適切なタイミングで呼び出されることを意味する.同様に、プロファイルメソッドのコールバックを構成するには、最上位レベル要素で'default-destroy-method'プロパティを使用します.
実現orgについてspringframework.beans.factory.BeanFactoryAwareインタフェースのクラスは、BeanFactoryによって作成されると、作成されたBeanFactoryへの参照を持ちます.つまりbeanにBeanFactoryへの参照を持たせることができる.しかし、一般的にはSpringにコードを結合し、回転制御の原則に違反するため、使用はできるだけ避けるべきである(協力者は属性としてbeanに提供すべきである).
ObjectFactoryCreatingFactoryBeanとBeanFactoryAwareの違いは、あるbeanがFactoryBeanを注入する後、依存するbeanがObjectFactoryによって提供されるため、依存beanに対してより多くの作業を行うことができるため、制御反転という原則に違反していないことである.
もしbeanがorgを実現したらspringframework.beans.factory.BeanNameAwareインタフェースは、BeanFactoryに配備されています.BeanFactoryは、そのインタフェースのsetBeanName()メソッドを使用して、配備時のbean idを通知します.beanプロパティの設定が完了すると、InitializingBeanのafterPropertiesSetやカスタムinit-methodのような初期化コールバックが実行される前に、インタフェースのコールバックメソッドが呼び出されます.
org.springframework.beans.factory.config.BeanPostProcessorインタフェースには、2つのコールバックメソッドがあります.インタフェースのインプリメンテーションクラスが登録されると(この登録を有効にするには以下を参照)、コンテナのポストプロセッサ(post-processor)として登録され、このコンテナによって作成されたbeanインスタンスごとに、afterPropertiesSetおよび任意の宣言されたinitメソッドなどの初期化メソッドが呼び出される前に、ポストプロセッサはコンテナからそれぞれコールバックを取得します.バックグラウンドプロセッサは、このbeanインスタンスに対して所望の動作を任意に実行することができ、このコールバックを完全に無視することを含む.1つのbeanバックグラウンドプロセッサは、通常、フラグインタフェースをチェックしたり、1つのbeanをproxyにパッケージしたりするために使用されます.いくつかのSpring AOPの下位処理もbeanバックグラウンドプロセッサを実装することによってエージェントパッケージロジックを実行する.
BeanPostProcessorを遅延初期化としてマークしないでください.そうすればSpringコンテナは登録されず、カスタムロジックは適用されません.要素の定義で'default-lazy-init'属性を使用している場合は、それぞれのBeanPostProcessorが'lazy-init="false"とマークされていることを確認してください.
SpringのBeanPostProcessorインプリメンテーションでフラグインタフェースを呼び出すか、注釈を使用することはSpring IoCコンテナを拡張する一般的な方法です.
BeanFactoryPostProcessorはbeanの定義(構成メタデータ)を処理できます.つまりSpring IoCコンテナでは、BeanFactoryPostProcessorが他のbeanを実際にインスタンス化する前に構成メタデータを読み込み、変更することができます.複数のBeanFactoryPostProcessorを構成します.また、「order」プロパティを設定することで、BeanFactoryPostProcessorの実行順序を制御することもできます(BeanFactoryPostProcessorがOrderedインタフェースを実装している場合にのみ設定できますので、BeanFactoryPostProcessorを実装する場合は、Orderedインタフェースの実装を考慮する必要があります).
PropertyPlaceholderConfigurerはbeanファクトリのバックグラウンドプロセッサの実装であり、BeanFactory定義の一部の属性値を別の標準Java Propertiesファイルに配置することができます.
PropertyOverrideConfigurerは別のbean factory processorです.propertiesファイルの値を使用して既存の値を上書きすることができます.
プロセスはインスタンスを変更し、定義を変更します.
FactoryBeanインタフェースは、Spring IoCコンテナに挿入され、インスタンス化ロジックをカスタマイズするためのインタフェースポイントです.冗長なXMLではなくJavaでよりよく表現できる複雑な初期化コードがあれば、独自のFactoryBeanを作成し、そのクラスに複雑な初期化動作を書き込み、カスタマイズしたFactoryBeanをコンデンサに挿入することができます.
-----spring bean id name
id属性ネーミングはXMLのネーミング仕様を満たさなければならない.idは実はXMLに限定されているからだ.まとめるとJava変数の名前に相当します.数字、記号で頭を打つことはできません.123などのスペースはありません.ad、abなどは規範化されておらず、Springは初期化時にエラーを報告します
nameプロパティにはこれらの制限はありません.ほとんどの名前を使用できます.例えば?ab,123などですが、スペースを付けることはできません.例えば「a b」「abc」です.この場合、初期化時にはエラーは報告されませんが、getBean()ではエラーが報告されます.
ただし、プロファイルには2つのnameが同じが表示され、getBean()でインスタンスを返すと、後のBeanが返され、前のが後の同名ので上書きされているはずです.これに鑑み,不用意な同名上書きを避けるためには,name属性ではなくid属性を用いることが望ましい.
nameプロパティは、などの複数の名前を区切って使用できます.複数の別名に相当します.この場合、getBean("a 1")getBean("a 2")getBean("a 3")によって返されるのは同じインスタンスです(singletonの場合と仮定します).
idとnameが指定されていない場合は、のようにクラスフルネームをnameとして使用すると、
getBean(「com.stamen.BeanLifeCycleImpl」)は、このインスタンスを返します.
<bean id="myDataSource" destroy-method="close"
class="org.apache.commons.dbcp.BasicDataSource">
<!-- results in a setDriverClassName(String) call -->
<property name="driverClassName">
<value>com.mysql.jdbc.Driver</value>
</property>
<property name="url">
<value>jdbc:mysql://localhost:3306/mydb</value>
</property>
<property name="username">
<value>root</value>
</property>
</bean>
idref要素は、コンテナ内の他のbeanのidを
<bean id="theTargetBean" class="..."/>
<bean id="theClientBean" class="...">
<property name="targetName">
<idref bean="theTargetBean" />
</property>
</bean>
上記bean定義フラグメントは、(実行時に)以下のフラグメントと完全に同等です.
<bean id="theTargetBean" class="..."/>
<bean id="client" class="...">
<property name="targetName">
<value>theTargetBean</value>
</property>
</bean>
第1の形式が第2の形式よりも望ましい主な原因は、idrefタグを使用して、コンテナが配置時に参照されたbeanが存在するかどうかを検証できることである.2つ目の方法では、client beanに渡されたtargetName属性値は検証されていません.
参照されたbeanが同じXMLファイル内にあり、beanの名前がbean idである場合、localプロパティを使用します.このプロパティを使用すると、XML解析器がXMLファイルを解析するときに参照されたbeanを検証できます.
次のようになります.
<idref local="theTargetBean"/>
depends−onプロパティは、現在のbeanを初期化する前に、1つ以上のbeanを明示的に初期化するために使用することができる.例えば、クラス内の静的ブロックの初期化が行う場合、例えばデータベース駆動の登録が行われる.複数のbeanへの依存を表す必要がある場合は、「depends-on」で指定した複数のbean名をカンマ、スペース、セミコロンなどで区切ることができます.
<bean id="beanOne" class="ExampleBean" depends-on="manager"/>
<bean id="manager" class="ManagerBean" />
ApplicationContextが実装するデフォルトの動作は、起動時にすべてのsingleton beanを事前にインスタンス化することです.アプリケーションContextの初期化時にsingleton beanを事前にインスタンス化したくない場合は、beanを遅延インスタンス化に設定できます.遅延初期化beanは、IoCコンテナが起動時にインスタンス化されるか、または最初に使用されるときにインスタンス化されるかを示す.XMLプロファイルでは、遅延初期化は
XML形式でbeanを構成する場合、
経験によれば、すべてのステータスのあるbeanに対してprototype役割ドメインを使用すべきであり、ステータスのないbeanに対してsingleton役割ドメインを使用すべきである.
Springを実現したInitializingBeanとDisposableBeanの2つのフラグインタフェースのbeanは,初期化と析出時にコンテナが前者のafterPropertiesSet()メソッドと後者のdestroy()メソッドを呼び出す.
InitializingBeanインタフェースの使用を避けるには(コードとSpringを結合するので、インタフェースの使用を奨励しません)、Bean定義で一般的な初期化方法を指定します.すなわち、XMLプロファイルでinit-methodプロパティを指定することで完了します.同様に、DisposableBeanフラグインタフェースの使用を回避します(Springにコードを結合するため、インタフェースの使用を奨励しません).bean定義で一般的なプロファイルメソッドを指定できます.すなわち、XMLプロファイルでdestroy-methodプロパティを指定することで完了します.
最上位レベル
実現orgについてspringframework.beans.factory.BeanFactoryAwareインタフェースのクラスは、BeanFactoryによって作成されると、作成されたBeanFactoryへの参照を持ちます.つまりbeanにBeanFactoryへの参照を持たせることができる.しかし、一般的にはSpringにコードを結合し、回転制御の原則に違反するため、使用はできるだけ避けるべきである(協力者は属性としてbeanに提供すべきである).
ObjectFactoryCreatingFactoryBeanとBeanFactoryAwareの違いは、あるbeanがFactoryBeanを注入する後、依存するbeanがObjectFactoryによって提供されるため、依存beanに対してより多くの作業を行うことができるため、制御反転という原則に違反していないことである.
もしbeanがorgを実現したらspringframework.beans.factory.BeanNameAwareインタフェースは、BeanFactoryに配備されています.BeanFactoryは、そのインタフェースのsetBeanName()メソッドを使用して、配備時のbean idを通知します.beanプロパティの設定が完了すると、InitializingBeanのafterPropertiesSetやカスタムinit-methodのような初期化コールバックが実行される前に、インタフェースのコールバックメソッドが呼び出されます.
org.springframework.beans.factory.config.BeanPostProcessorインタフェースには、2つのコールバックメソッドがあります.インタフェースのインプリメンテーションクラスが登録されると(この登録を有効にするには以下を参照)、コンテナのポストプロセッサ(post-processor)として登録され、このコンテナによって作成されたbeanインスタンスごとに、afterPropertiesSetおよび任意の宣言されたinitメソッドなどの初期化メソッドが呼び出される前に、ポストプロセッサはコンテナからそれぞれコールバックを取得します.バックグラウンドプロセッサは、このbeanインスタンスに対して所望の動作を任意に実行することができ、このコールバックを完全に無視することを含む.1つのbeanバックグラウンドプロセッサは、通常、フラグインタフェースをチェックしたり、1つのbeanをproxyにパッケージしたりするために使用されます.いくつかのSpring AOPの下位処理もbeanバックグラウンドプロセッサを実装することによってエージェントパッケージロジックを実行する.
BeanPostProcessorを遅延初期化としてマークしないでください.そうすればSpringコンテナは登録されず、カスタムロジックは適用されません.
SpringのBeanPostProcessorインプリメンテーションでフラグインタフェースを呼び出すか、注釈を使用することはSpring IoCコンテナを拡張する一般的な方法です.
BeanFactoryPostProcessorはbeanの定義(構成メタデータ)を処理できます.つまりSpring IoCコンテナでは、BeanFactoryPostProcessorが他のbeanを実際にインスタンス化する前に構成メタデータを読み込み、変更することができます.複数のBeanFactoryPostProcessorを構成します.また、「order」プロパティを設定することで、BeanFactoryPostProcessorの実行順序を制御することもできます(BeanFactoryPostProcessorがOrderedインタフェースを実装している場合にのみ設定できますので、BeanFactoryPostProcessorを実装する場合は、Orderedインタフェースの実装を考慮する必要があります).
PropertyPlaceholderConfigurerはbeanファクトリのバックグラウンドプロセッサの実装であり、BeanFactory定義の一部の属性値を別の標準Java Propertiesファイルに配置することができます.
PropertyOverrideConfigurerは別のbean factory processorです.propertiesファイルの値を使用して既存の値を上書きすることができます.
プロセスはインスタンスを変更し、定義を変更します.
FactoryBeanインタフェースは、Spring IoCコンテナに挿入され、インスタンス化ロジックをカスタマイズするためのインタフェースポイントです.冗長なXMLではなくJavaでよりよく表現できる複雑な初期化コードがあれば、独自のFactoryBeanを作成し、そのクラスに複雑な初期化動作を書き込み、カスタマイズしたFactoryBeanをコンデンサに挿入することができます.
-----spring bean id name
id属性ネーミングはXMLのネーミング仕様を満たさなければならない.idは実はXMLに限定されているからだ.まとめるとJava変数の名前に相当します.数字、記号で頭を打つことはできません.123などのスペースはありません.ad、abなどは規範化されておらず、Springは初期化時にエラーを報告します
nameプロパティにはこれらの制限はありません.ほとんどの名前を使用できます.例えば?ab,123などですが、スペースを付けることはできません.例えば「a b」「abc」です.この場合、初期化時にはエラーは報告されませんが、getBean()ではエラーが報告されます.
ただし、プロファイルには2つのnameが同じ
nameプロパティは、
idとnameが指定されていない場合は、
getBean(「com.stamen.BeanLifeCycleImpl」)は、このインスタンスを返します.