2008年06月07日

Preface

まえがき

よいツールと技術に恵まれていてもアプリケーションの開発は難しいものです。まして、重量級なだけでコントロールが難しく、開発サイクルにおいて非効率な、「何でもできる」プラットフォームをつかった開発は困難を極めます。Springは、宣言的トランザクションやRMI/WEBサービスを使用するリモートアクセス、多様なデータベースアクセスの手法を提供しながらも、エンタープライズアプリケーションのの構築に耐えうる軽量なフレームワークです。Springは、MVCフレームワークを提供し、AOPによる透過的なソフトウェアの統合を実現します。

いかなるエンタープライズアプリケーションでも、その全体にわたってSpringを使用することができます。しかしSpringはモジュール構造をしているので、必要な部分だけを使用し他は導入しない、ということが可能です。つまり、Strutsを上位層としてIoCコンテナを使うこともできますが、Hibernate 統合コードやJDBC抽象化レイヤだけを使うこともできるということです。Springは煩雑さをさけ、またフレームワーク自身に対して通常はまったく依存しない(あるいは状況に応じた最小の依存ですむ)ことを意図して設計されています。

この文書はSpringのさまざまな機能へのリファレンスガイドです。まだまだ作成途中ですので、提案やコメントがあればユーザメーリングリストかサポートフォーラム(http://forum.springframework.org/)に投稿してください(訳注:この日本語訳に関する事項は投稿しないでください)。

ここでHibernateチームのChristian Bauerに謝辞を述べておきます。かれはHibernateのリファレンスを作成するため、またこの文書を作成できるようにするためDocBook-XSLの改変などといった準備を行ってくれました。広範囲にわたり価値のあるレビューを行ってくれたRussel Healyにも感謝します。

原文:http://static.springframework.org/spring/docs/2.5.x/reference/preface.html
ラベル:SpringFramework2.5

Chapter 1. Introduction

第1章 はじめに
広い意味での(制限つきのアプレットから、階層構造でサーバサイドな本格的エンタープライズアプリケーションまでを含む)Javaアプリケーションは、通常多くのオブジェクトの協働によってアプリケーションとして正常な動作をします。ですからオブジェクト間には依存性があるといえます。

Java言語とJavaプラットフォームは、プリミティブ型やクラス、新たなクラスを定義する手段といったごく基本的なものから、多機能なアプリケーションサーバやウェブフレームワークにいたる広い範囲にわたって、アプリケーションを設計・構築するための豊富な機能を提供してくれます。しかし、基本的なコードブロックを、わかりやすくひとつのものにまとめ上げる手段がなく、だいたいの場合アプリケーションを構築する役割の設計者や開発者がそれを提供することになります。公平を期すために言及しておくと、多機能なアプリケーションを構成するためのさまざまなクラスやインスタンスを組み立てるために、たくさんのデザインパターンが役立ちます。いくつかの例を挙げると、Factory、Abstract Factory、Builder、Decorator、Service Locatorなどのパターンがありますが、これらのパターンはソフトウェア構築業界では幅広く知られ、受け入れられています(だからこそこれらのパターンがパターンとして定義されたとも言えるでしょう)。デザインパターンが役に立つことは確かですが、しかしそれは名前のついたベストプラクティスでしかなく、そのパターンが何をするためのものであり、どういう場合に適用すると効果的で、どういう問題を解決することができるのか、等々が述べられているに過ぎません。デザインパターンの本やWikiはたいがい「…このパターンができることは、…」という文句を最後の段落で使って、こうした様式化されたパターンをリストアップしているだけで、それを持ち帰り、深く考え、そしてアプリケーションに実装するのは開発者の仕事なのです。

Spring FrameworkのIoCコンポーネントは、各種それぞれの特性を持ったコンポーネントを動作・使用が可能なアプリケーションに組み上げるための定型化された手段を提供することによって、アプリケーションを構成するクラスやオブジェクト、サービスの選択に関する企業の心配事を取り除くことを狙いとしています。Spring Frameworkは、何年もかけていくつものアプリケーションを経て検証されてきたベストプラクティスとデザインパターンを利用しています。そしてそのパターンを実際にコードに落とし込み、設計者・開発者がアプリケーションに組み込むことができるクラスとして提供しています。これは確かに非常に良いことであるということが、たくさんの組織がSpring Frameworkを使用して堅牢で保守性の高いアプリケーションを開発したという実績によって証明されています。

背景

2004年のはじめ、Martin Fowlerは彼のサイトでIoC:Inversion of Control(制御の反転)について読者に「制御の何を反転させるのかということがよくわからない」という疑問を投げかけました。そしてFowlerはもっと説明的な名前をつけてはどうかと提案し、そこからDI:Dependency Injection(依存性の注入)という用語を使用するようになりました。彼の記事にはさらにIoCとDIという概念を裏打ちしている考えに対する解説が記されています。IoCやDIについての優れた分析を知りたい場合には彼の記事を参照すると良いでしょう。http://martinfowler.com/articles/injection.html(訳注:http://kakutani.com/trans/fowler/injection.htmlに角谷 信太郎氏による和訳があります)


原文:http://static.springframework.org/spring/docs/2.5.x/reference/introduction.html
ラベル:SpringFramework2.5

2008年06月11日

1.1 Overview

1.1 概要

Spring Frameworkではその多彩な機能を、下図に示した6つのモジュールとして提供しています。この章では各モジュールを順に見ていきましょう。

[図:Spring Frameworkの概観]

「Core」パッケージはSpringの核となる部分で、IoC/DI機能を提供します。Coreパッケージの基本概念であるBeanFactoryはFactoryパターンの機能を持つ洗練されたクラスです。これによって、Singletonのコーディングは不要になり、プログラムロジックを設定と仕様への依存から解放します。

「Context」パッケージはCoreパッケージの補助的なもので、JNDIレジストリサービスのような方法でオブジェクトにアクセスする方法を提供します。ContextパッケージはBeansパッケージからその機能を引き継いでおり、それに加えて国際化(たとえばリソースバンドルの使用)、イベントの繰り上げ(event propagation)、リソースのロード、サーブレットコンテナ等の外部で作成されたコンテキストの使用に対応しています。

「Dao」パッケージは、単調なJDBCの実装やデータベース固有のエラーコード解析の手間を省くための、JDBC抽象化レイヤーを提供します。さらに、宣言的トランザクションおよびプログラム制御トランザクションを、特定のインターフェイスを実装したクラスだけでなく、POJO(Plain Old Java Objects)に対しても提供します。

「ORM」パッケージは一般的なO/RマッピングAPI(JPA、JDO、HibernateおよびiBatis)をSpringから使用するためのパッケージです。ORMパッケージはこれらのO/Rマッピングフレームワークを、Springが提供する他の機能(たとえば前述の宣言的トランザクション管理など)と同時に使用することができます。

「AOP」パッケージはAOP Allianceに準拠したアスペクト指向プログラミングの機能を提供します。これによりメソッドのインターセプトやポイントカットを使用して、論理的には分割されるべき機能を分離することができます。またソースレベルメタデータ機能を使用することでコード中にそのコードの振る舞いに関する情報を組み込むことができます。これは.Netの「属性」に似た機能です。

「Web」パッケージはファイルの分割アップロードや、サーブレットリスナを使用したIoCコンテナの初期化、Web向けアプリケーションコンテキストといった機能を持つ、Web指向の統合パッケージです。WebWorkあるいはStrutsをSpringとともに使用する際にも必要となるパッケージです。

「MVC」パッケージはWebアプリケーション向けのMVC(Model-View-Controller)実装を提供します。SpringのMVCフレームワークは単なるMVCではなく、ドメインモデルとWebフォームを完全に切り離し、さらに他のSpringの機能を使用できる環境を提供します。

原文:http://static.springframework.org/spring/docs/2.5.x/reference/introduction.html#introduction-overview
ラベル:SpringFramework2.5

1.2 Usage Scenarios

上述した各モジュールを使用して、さまざまな状況でSpringを使用することができます。アプレットから本格的なエンタープライズアプリケーションにいたるまで、Springのトランザクション管理機能やWeb統合機能を使用することができます。

[図:Springを使用した本格的なWebアプリケーションの典型]

Springの宣言的トランザクションマネジメントによって、WebアプリケーションにEnterprise Java Bean(EJB)のコンテナ管理トランザクションを使用するのと同様のトランザクション管理を適用することができます。すべてのビジネスロジックは、IoCコンテナ管理の下でシンプルなPOJOとして実装することができます。Web層から独立ているE-mail送信やバリデーションなどの補助的なサービスは、バリデーションルールを適用する場所を制限しません。ORMサポート機能はJPA、Hibernate、JDO、iBatisと違和感なく統合されています。たとえばHibernateを使用する際に既存のマッピングファイルとHibernate標準のSessionFactoryの設定を使用することができます。フォームコントロールはドメインモデルを持つWeb層と統合され、ActionFormやHTTPパラメータをドメインモデルに詰め替えるという作業を不要なものとします。

[図:サードパーティのWebフレームワークを使用したSpringの中間層]

完全に別のフレームワークに移行するということができない状況ということもあるでしょう。Spring Frameworkはそのすべてを使用することを強いる仕組みは採用していません。WebWork、Struts、Tapestryあるいはその他のUIフレームワークを使用した既存のフロントエンドを、Springのトランザクション機能を使用した中間層とをきれいに統合することは簡単なことです。しなければならない事は、ビジネスロジックをApplicationContextを使用して組み上げ、WebApplicationContextを使用してWeb層をまとめ上げることだけです。

[図:リモート使用シナリオ]

Webサービスを使用して既存のコードにアクセスする場合は、SpringのHessianProxyFactory、BurlapProxyFactory、RmiProxyFactory、JaxRpcProxyFactoryのいずれかを使用することができます。既存のアプリケーションに、ある日から急にリモートアクセスすることになったとしても、それはもはや難しいことではありません。

[図:既存のPOJOをラップするEJB]

Spring FrameworkはEJBへのアクセスレイヤおよび抽象化レイヤを提供します。これにより既存のPOJOをStateless Session Beanにラップすることができます。これは宣言的セキュリティを必要とする拡張性がありフェイルセーフなWebアプリケーションの一部としてこのPOJOを再利用できるということです。

原文:http://static.springframework.org/spring/docs/2.5.x/reference/introduction.html#overview-usagescenarios
ラベル:SpringFramework2.5

2008年06月13日

2.1 Introduction

2.1 導入

Spring Frameworkをすでに使用している方であれば、2006年10月にリリースされたSpring 2.0と2007年11月にリリースされたSpring 2.5の2種類のバージョンがあることにお気づきかもしれません。この章ではSpring 2.0と2.5での新機能および改善点を紹介します。この章は、Springをすでによく知っている設計者・開発者が、手早くSpring 2.Xの各種の機能を知るための大まかな要約を示すことを目的としています。さらに詳しい情報はそれぞれに対応するリンク先の章を参照してください。


Java SEとJava EEのサポート

Spring FrameworkはJava 1.4.2を含むそれ以降のすべてのバージョンのJavaとの互換性を保っています。つまりJava 1.4.2、Java 5、Java 6 をサポートしています。しかしながらJava 1.4.2ではSpringの機能のうちいくつかの高度な機能が使用できません。Spring 2.0でフレームワーク全体の徹底的なJava 5対応の後、Spring 2.5ではJava 6に向けたサポートが導入されました。
それと同時に、SpringはJava EE 5に対応していますが、J2EE 1.3以上であれば互換性を保っています。つまりSpringは以下のアプリケーションサーバ上で一貫して使用できるということです:BEA WebLogic 8.1/9.0/ 9.2/ 10、Oracle OC4J 10.1.3/11、JBoss 3.2/4.0/4.2、Tomcat 4.1/5.0/ 5.5/ 6.0、Jetty 4.2/ 5.1/ 6.1、Resin 2.1/ 3.0/ 3.1 GlassFish V1/V2。


原文:http://static.springframework.org/spring/docs/2.5.x/reference/new-in-2.html#new-in-2-intro
ラベル:SpringFramework2.5

2008年06月15日

2.2. The Inversion of Control (IoC) container

2.2 IoC コンテナ

IoCコンテナはバージョン2.0および2.5において多くの機能改善がなされた部分です。

2.2.1 新規のBeanスコープ
Springの以前のバージョンでは、Beanスコープを二種類(シングルトンとプロトタイプ)だけサポートするIoCコンテナレベルがありました。Spring 2.0ではSpringがデプロイされる環境に依存したスコープ(たとえばWeb環境におけるRequestスコープやSessionスコープなど)が追加され、さらに統合ポイントが提供されることによってユーザ自身でスコープを作成することができるようになりました。

シングルトンスコープおよびプロトタイプスコープを持つBeanの基礎となる内部的な実装は変更されていますが、この変更はユーザには影響を与えません。既存の設定は変更することなく、また設定が壊れることなく引き続き使用することができます。

新しいスコープと既存のスコープについての詳細は3.4章 「Beanスコープ」に記述されています。

2.2.2 扱いやすいXMLによる設定
SpringのXML設定は、XMLスキーマに基づく構文の改良によりだいぶ簡単なものになりました。Springが新しく提供するタグを活用するためには、付録A 「XMLスキーマに基づく設定」を参照してください。新しいタグを使用することによって設定の無駄を省き、可読性を上げることができるため、Springチームはこれを使用することを推奨します。

さらに、XMLスキーマベースの設定が使用できない場合に参照する必要があれば、Spring 2.0のためにアップデートされたDTDを使用することができます。下に示したDOCTYPE宣言をそのまま使用することができますが、興味をもたれた方は、Spring2.5配布ディレクトリに含まれる「dist/resources」ディレクトリ下の「spring-beans-2.0.dtd」を読まれることをお勧めします。


<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN 2.0//EN"
"http://www.springframework.org/dtd/spring-beans-2.0.dtd">


2.2.3 拡張可能なXML記述
XML設定は容易に記述できるだけでなく、拡張可能なものとなりました。
「拡張可能」という言葉が意味するところは、利用者自身(つまり開発者やサードパーティフレームワークや製品の提供者)がカスタムタグを作成し、他の開発者がそれをSpringのコンフィグファイル中で使用できるということです。これによって個別のコンポーネントの設定の中に、ユーザが扱っている(広い意味での)領域に特有の用語を反映させることができる様になります。
Springのカスタムタグを作成することは、個々のプロジェクトのアプリケーション開発者やエンタープライズアーキテクトにとっては興味のないことでしょう。しかしサードパーティのベンダにとって、Springコンフィグファイル中で使用できる独自の設定用タグを開発することが魅力的と感じてもらえることを期待しています。
コンフィグの拡張機構については付録B 「拡張可能なXML記述」に記してあります。

2.2.4 アノテーションを使用した設定
Spring 2.0からさまざまなアノテーションが設定のために導入されました。たとえば@Transactional、@Required、@PersistenceContext、@PersistenceUnitなどが挙げられます。
Spring 2.5ではさらに設定を完全にこなせるだけのアノテーションを導入しました。JSR-250アノテーションである@Resource、@PostConstruct、@PreDestroyのサポートとともに@Autowiredが追加されました。
アノテーションを使用したBeanの設定は3.11章 「アノテーションによる設定」にて示されています。Spring MVCにおけるアノテーションのサポートについては2.5.3章 「アノテーションベースのコントローラ」についても参照してください。

2.2.5 クラスパスにあるコンポーネントの自動検出
Spring 2.5ではコンポーネントスキャンによって、クラスパスに配置されているアノテーションを使用したコンポーネントを自動検出することができます。一般的にそのようなコンポーネントクラスには@Component、@Repository、@Service、@Controllerといったステレオタイプアノテーションが記述されるはずです。ApplicationContextの設定しだいでそのようなコンポーネントクラスを自動検出の対象としてSpringのBean定義に組み込むことができます。その際にはそれぞれのBeanのための明示的な設定は必要ありません。
アノテーションを使用したBeanの設定は3.12.1章 「@Componentとその他のステレオタイプアノテーション」にて述べられています。
ラベル:SpringFramework2.5

2008年06月17日

2.3. Aspect Oriented Programming (AOP)

2.3 アスペクト指向プログラミング(AOP)

Spring 2.0では洗練されたAOP機能が提供されています。SpringのAOPフレームワークでは驚くほど簡単にXMLによる設定が可能で、また結果として冗長性を激減させています。またSpringはAspectJポイントカット言語と@AspectJ方式のアスペクト定義スタイルを統合しています。第6章 「Springによるアスペクト指向プログラミング」がこの点に関する記述に割かれています。

2.3.1 簡単なXMLによるAOPの設定
Spring 2.0では新たにアスペクトの定義のためのスキーマがサポートされています。この機能はAspectJのポイントカット言語を利用したもので型付のAdviceを使用することができます(つまりキャストやObject[]による引数の指定が不要ということです)。詳細は6.3節 「スキーマベースのAOPサポート」を参照してください。

2.3.2 @AspectJアスペクトのサポート
Spring 2.0では@AspectJアノテーションを使用したアスペクトの定義もサポートしています。このアスペクト定義はAspectJとSpring AOPで共有することができますし、いくつかのシンプルな設定が必要となるだけです。@AspectJアスペクトについては6.2節 「@AspectJのサポート」において言及されています。

2.3.3 Bean名ポイントカット要素のサポート
Spring 2.5から bean(...) タイプのポイントカット要素(つまりSpringが定義している特定の名前を持つBeanにマッチする要素)がサポートされています。6.2.3.1項 「サポートされているポイントカット識別子」を参照してください。

2.3.4 AspectJの実行時ウィーブのサポート
Spring 2.5ではプロキシベースのAOPフレームワークの代替手段として、AspectJの実行時ウィーブをサポートしています。新し区導入された context:load-time-weaver を設定することで、 META-INF/aop.xml ファイルによって定義されるAspectJアスペクトを自動的に有効にすることができます。これにより、使用されているClassLoaderをバイトコード変換プログラムに登録して、アプリケーションコンテキストにアスペクトを適用します。6.8.4項 「Spring Framework上でのAspectJ実行時ウィーブ」に可能なことと制限事項が記されています。

原文:http://static.springframework.org/spring/docs/2.5.x/reference/new-in-2.html#new-in-2-aop
ラベル:SpringFramework2.5

2008年06月18日

2.4. The Middle Tier

2.4 中間層

2.4.1 XMLによる宣言的トランザクションの簡単な設定
Spring 2.0からはトランザクションの設定方法が大きく変わりました。1.2.x方式の設定を使用し続けることもできますが、新方式では大幅にシンプルに設定を行うことができるためこちらを使用することをお勧めします。またAOPライブラリとしてAspectJを同梱しているので、どのようなオブジェクトでも(SpringのIoCコンテナによって生成されていないようなものでも)トランザクションに組み入れることができます。
バージョン2.5からはアノテーションによる便利なトランザクション管理がサポートされています。アノテーションによるトランザクション管理において、 tx:annnotation-driven mode="aspectj" という設定と同時に context:load-time-weaver を設定することによって実行時ウィーブを行うこともできます。
第9章 「トランザクション管理」に詳細が記されています。

2.4.2 WebSphereトランザクション管理の完全なサポート
Spring 2.5ではIBMのWebSphereアプリケーションサーバを(特にWeb Sphereのトランザクションマネージャにかかわる部分について)正式にサポートしています。WebSphereで新たに追加されたUOMManager API(WAS 6.0.2.19以上または6.0.1.9以上から利用できます)を使用することにより、トランザクションの一時停止を完全にサポートしています。
Springを使用したアプリケーションをWebSphereアプリケーションサーバ上で動作させる場合はバージョン2.5からのWebSphereUowTransactionManagerをPlatformTransactionmanagerとして使用されることを強く推奨します。これはIBMが公式に推奨している方法でもあります。

2.4.3 JPA
Spring 2.0はJPA抽象化レイヤを持っています。これはJDBC抽象化レイヤと使用される範囲やパターンにおいて似たような範囲をカバーしています。
JPA実装を永続層として採用することに興味があるのであれば、12.6節 「JPA」にその機能と役割が説明されています。

2.4.4 非同期JMS
バージョン2.0よりも前のバージョンでは、SpringのJMS機能はメッセージの送信と同期メッセージの受信に限られていました。この(JmsTemplateクラスに集約されていた)機能はすばらしい機能でしたが、非同期メッセージの受信への要求に応えるものではありませんでした。
Spring 2.0ではこの点を改め、非同期なメッセージの受信を完全にサポートしています。これは19.4.2節 「非同期メッセージ受信 - メッセージドリブンPOJO」にて詳解されています。
またSpring2.5からはJCA形式の非同期メッセージリスナの登録もサポートしています。これにはGenericMessageEndpointManagerを使用します。これは標準のJMSリスナ機構の代替手段となるもので、ActiveMQやJORAMといったメッセージブローカとより密に統合されたものとなっています。19.5節 「JMS名前空間のサポート」を参照してください。

2.4.5 JDBC
いくつかの小さな(それでいて重要な)クラスが、SpringFrameworkのJDBCライブラリに追加されています。ひとつはNamedParameterJdbcTemplateで、これは従来のJDBCステートメントが名前を持たない「?」プレースホルダのみを使用していたのに対して、名前付のパラメータ機能を使用できるようにするものです。
2つめはJava 5 (Tiger)以上の環境でJdbcTemplateをより簡単にしたSimpleJdbcTemplateです。
Spring 2.5ではSimpleJdbcTemplateの機能を大幅に拡張し、SimpleJdbcCallとSimpleJdbcInsertというオペレーションオブジェクトを新たに導入しています。

原文:http://static.springframework.org/spring/docs/2.5.x/reference/new-in-2.html#new-in-2-middle-tier
ラベル:SpringFramework2.5

2008年06月21日

2.5. The Web Tier

2.5 Web層
Web層の機能はSpring 2.0で大幅に改善・拡張されました。また2.5からはアノテーションに基づくコントローラも導入されています。

2.5.1 Spring MVCにおける実用的な省略
多くのプロジェクトにとって、規約を厳守することと合理的な省略は真に必要なこととなっています。Spring MVCではこの「設定に勝る規約(Convention-over-configuration」というテーマをしっかりとサポートしています。つまり命名規約をコントローラとビューに対して確立することによって、ハンドラマッピングやビューの解決、ModelAndViewインスタンスなどの設定に必要なXMLの記述量をかなり圧縮することができるのです。このことはすばやいプロトタイプ作成が可能になるという点において、またコードベースに好ましい一貫性を持たせるという点において大きな恩恵をもたらします。Spring MVCのconvention-over-configurationについては13.10節 「Convention over Configuration」にて述べられています。

2.5.2 ポートレットフレームワーク
Spring 2.0はSpring MVCと概念上は良く似たポートレットフレームワークを備えています。ポートレットフレームワークが受け持つ分野に関しては第16章 「ポートレットMVCフレームワーク」で述べられています。

2.5.3 アノテーションに基づくコントローラ
Spring 2.5は(@RequestMappingや@RequestParam、@ModelAttributeなどのアノテーションを使用した)アノテーションベースの設定をMVCコントローラに導入しました。アノテーションのサポートはサーブレットMVCでもポートレットMVCでも使用することができます。この形式を使用する場合にはコントローラに特定のクラスあるいはインタフェースを継承・実装させる必要はありません。またサーブレットやポートレットのAPIに対して直接の依存関係を持っていません(必要であれば直接アクセスすることもできます)。より詳しい情報は13.11節 「アノテーションによるコントローラの設定」に記しています。

2.5.4 Spring MVC用Formタグライブラリ
充実したJSPタグライブラリはJIRAで圧倒的に多くのユーザからの票を得た課題でした。Spring 2.0では多機能なJSPタグライブラリを備え、Spring MVCを使用したJSPの作成をより簡単なものにします。このSpringチームはこのタグライブラリが、JIRAで投票したすべての人を満足させるものであると確信しています。14.2.4節 「タグライブラリからのスプリングの使用」にこのライブラリについての情報があります。また付録E 「spring-form.tld」にタグのクイックリファレンスがあります。

2.5.5 Tiles 2のサポート
バージョン2.5からTiles 2(テンプレートフレームワークTilesの次世代バージョンです)をサポートしています。これは以前のバージョンでのStruts 1.xに含まれていたTiles 1のサポート機能に取って代わるものです。14.3節 「Tiles」を参照してください。

2.5.6 JSF 1.2のサポート
Spring 2.5ではJSFをサポートしています。これはSpringBeanFacesELResolverのフォームにおけるDelegatingVariableResolverのJSF 1.2バリアントとして提供されています。

2.5.7 JAX-WS
Java 6およびJava EE 5に含まれているJAX-WS 2.0/2.1もSpring 2.5ではサポートしています。JAX-WSはJAX-RPCの後継で、WSDL/SOAPによるウェブサービスへのアクセスと、ウェブサービスのJAX-WSスタイルで公開することができるようになります。

原文:http://static.springframework.org/spring/docs/2.5.x/reference/new-in-2.html#new-in-2-web
ラベル:SpringFramework2.5

2.6. Everything else

2.6 そのほかの新機能
最後の節ではSpring 2.0/2.5のその他の新機能や改善点の概要を挙げてあります。

2.6.1 動的言語のサポート
Spring 2.0からはJava以外の言語(現在はJRuby、GroovyそしてBeanShellをサポートしています)で書かれたBeanを使用することができます。動的言語のサポートは第24章 「動的言語のサポート」に述べられています。
Spring 2.5では最新リリースのJRuby 1.0への対応と自動ワイヤリングのサポートが追加されています。

2.6.2 テスト環境の強化
バージョン2.5からSpring TestContextフレームワークが導入されました。このフレームワークは使用するテスティングフレームワークに関係なく、アノテーション駆動の単体・結合テスト環境を提供します。つまり、たとえばJUnit 3.8で使用したテクニックとアノテーションによる設定が、JUnit 4.4やTestNGなどを使用したテストにも適用できるということです。
Spring TestContextフレームワークは、汎用的で拡張性のあるテスト環境を提供するだけでなく、設定不要で使用できるSpring特有の結合テスト機能(「コンテキスト管理とキャッシュ、テスト手順のDI」およびデフォルトのロールバック動作による「トランザクションを使用するテストの管理」といったもの)を提供します。
単体・結合テストの補助機能に関する情報は改訂されたテストに関する章中の8.3.7項 「Spring TestContextフレームワーク」を参照してください。

2.6.3 JMXサポート
Spring 2.0ではJMXの通知(Notification)をサポートします。MBeanをMBeanServeに登録する際の動作を宣言的なコントロールを行うことも可能です。

  • 20.7節 「通知」
  • 20.2.5項 「登録時の動作をコントロールする」

さらにSpring 2.5からは設定用の context:mbean-export 要素がBeanクラスを簡易に登録するために追加されており、Beanに記述された@ManagedResourcesアノテーションを読み取ることができます。

2.6.4 JCAアダプタとしてSpringアプリケーションコンテキストをデプロイする
Spring 2.5ではSpringアプリケーションコンテキストをJCAのRARファイルにまとめられたリソースアダプタとしてデプロイすることができます。これによってJ2EEサーバのすべての基幹部分にアクセスする(たとえばスケジュールされたタスクを実行したり、メッセージ受信を監視したりするなどを行う)ヘッドレスなアプリケーションモジュールとしてJ2EEサーバにデプロイすることができます。

2.6.5 タスクのスケジュール
Spring 2.0はタスクのスケジューリングに関する抽象化機能を持っています。関心のある方は23.4節 「TaskExecutorの抽象化」を参照してください。
TaskExecutorによる抽象化は、たとえば非同期JMSのサポートなどフレームワーク自身においても使用されています。またSpring 2.5ではJCA環境のサポートにおいても使用されます。

2.6.7 Java 5(Tiger)のサポート
以下のリンク先にSpring 2.0および2.5におけるJava 5のサポートについての文書があります。

  • 3.11節 「アノテーションによる設定」
  • 25.3.1項 「@Required」
  • 9.5.6項 「@Transactionalの使用」
  • 11.2.3項 「SimpleJdbcTemplate」
  • 12.6節 「JPA」
  • 6.2節 「@AspectJのサポート」
  • 6.8.2項 「Springと同時にAspectJをドメインオブジェクトのDIに使用する」


原文:http://static.springframework.org/spring/docs/2.5.x/reference/new-in-2.html#new-in-2-other
ラベル:SpringFramework2.5

2008年06月23日

2.7. Migrating to Spring 2.5

2.7 Spring 2.5への移行
最後に、Spring 1.2や2.0からSpring 2.5への移行に関する注意点などについて述べていきます。
Spring 2.0.xからSpring 2.5へのアップグレードは、単にSpring 2.5のJarファイルをアプリケーションのディレクトリ構造の適当な場所に配置するだけです。JDK 1.4.2以上で実行されるSpring 2.0アプリケーションはSpring 2.5にアップグレードすることを強くお勧めします。Java 5以降のアプリケーションであればなおさらです。Spring 2.5は設定の大幅な簡便化とパフォーマンスの改善を行っているため、その恩恵を受けることができます。
Spring 1.2.xからのアップグレードがどのくらいスムーズに行えるかは、コード中でどれだけSpringのAPIを使用しているかにかかっています。Spring 2.0では、バージョン1.2.xでdeprecatedとされていたクラスとメソッドはすべて削除されています。そのためこれらのクラス・メソッドを使用していた部分では、代わりのクラス・メソッドを使用する必要があります(いくつかは後ほど述べます)。
設定ファイルに関してはSpring 1.2.x形式のXML設定ファイルはSpring 2.5のライブラリでも100%使用することができます。Spring 1.2.xのDTDを使用している場合にはSpring 2.0以降の機能(スコープやより簡単になったAOP、トランザクション設定など)を利用する事ができませんが、今までの設定ファイルが使えなくなってしまうことはありません。
移行戦略の一つとしては、Spring 2.5の機能改善(バグフィックスや最適化など)を利用するためだけにSpring 2.5のJarを使用することです。そして少しずつSpring 2.5の新機能や設定を使用していきます。たとえばAoPの部分にだけSpring 2スタイルの設定を導入することができます。設定の90%を旧式のSpring 1.2.xのDTDを使用したXMLで行い、残りの10%に2.0/2.5のDTDやXSDを適用することには何の問題もありません。

2.7.1 変更点
変更点を列挙したわかりやすいリストはSpring Framework配布ディレクトリのトップに「changelog.txt」として配置してあります。

2.7.1.1 サポートしているJDKのバージョン
Spring 2.5からJDK 1.3は、2006年後半にSunが公式に非推奨としたことに従いサポートされなくなりました。JDK 1.4.2へのアップグレードがまだの方はアップグレードしたほうが良いでしょう。
WebSphere 4.0や5.0などJDK 1.3のみに対応しているアプリケーションサーバを使用し続ける必要があるならば、JDK 1.3に対応しているSpring 2.0.7/2.0.8を使用することをお勧めします。

2.7.1.2 Spring 2.5のJarパッケージ
Spring 2.5からはSpring Web MVCは「spring.jar」には含まれていません。Spring MVCはlib/modulesディレクトリ中の「spring-webmvc.jar」ファイルと「spring-webmvc-portlet.jar」ファイルに含まれています。さらに、Struts 1.Xのサポートは「spring-webmvc-struts.jar」に外部化されています。
※ よく使用されるDispatcherServletクラスはSpring Web MVCに属しています。したがって(HessianやHTTPを使用した起動サービスなどの)リモートアクセスのためにDispatcherServletのみを使用する場合でも、「spring-webmvc.jar」(もしくは「spring-webmvc-portlet.jar」「spring-webmvc-struts.jar」)を「spring.jar」とともに使用する必要があります。
Spring 2.0の「spring-jmx.jar」と「spring-remoting.jar」はバージョン2.5では「spring-context.jar(JMXとHTTP以外でのリモートアクセスサポート)」に統合され、また一部は「spring-web.jar(HTTPでのリモートアクセスサポート)」に組み込まれています。
「spring-support.jar」は正しい意味合いをあらわすために「spring-context-support.jar」に名前が変更されました。「spring-portlet.jar」も同様に、技術的にSpring Web MVCフレームワークのサブモジュールであるため「spring-webmvc-portlet.jar」という名前になっています。「spring-struts.jar」から「spring-webmvc-struts.jar」への名前変更も同じ理由です。
Spring 2.0での「spring-jdo.jar」、「spring-dao.jar」、「spring-hibernate3.jar」、「spring-toplink.jar」、「spring-ibatis.jar」の各種のファイルは「spring-orm.jar」にひとまとめにされています。
「spring-mock.jar」はSpring 2.5ではTestContextフレームワークに焦点を絞った「spring-test.jar」に置き換えられました。しかし「spring-test.jar」には「spring-mock.jar」の内容がすべて含まれているので、既存の単体・結合テストで使用する場合でもそのまま置き換えることができます。
Spring 2.5で導入された「spring-tx.jar」はトランザクションフレームワークとして以前のバージョンの「spring-dao.jar」と「spring-jca.jar」を置き換えるものです。
Spring 2.5はOSGi準拠のJarとして配布されています。したがってOSGi環境でSpringを使用する際にも、パッケージしなおす必要はありません。

2.7.1.3 XMLによる設定
Spring 2.0では以前のバージョンで使用されていたDTDの代わりに、より洗練された方法でXMLのメタ情報を記述できるXSDを採用しています。以前のDTDも継続してサポートされていますが、できることならXSDへの参照を設定ファイルに記述することを推奨します。
大きく変わった点のひとつにはBeanのスコープ定義の方法があります。Spring 1.2のDTDを使用していれば「singleton」属性を使い続けることができますが、代わりに「scope」属性を使用することで「singleton」属性が使用できないSpring 2.0のDTDを参照することもできます。

2.7.1.4 非推奨のクラスとメソッド
以前から@deprecatedとされていた多くのクラスとメソッドがSpring 2.0で削除されました。Springチームは、2.0のリリースは新たな始まりであり、将来の見通しのためには非推奨な「がらくた」がコードにとり憑いたままにするよりは取り除いてしまった方が良いと考えたのです。
上述のとおり、Springの配布ファイルのトップディレクトリにある、「changelog.txt」を参照してください。このファイルには変更点がわかりやすい様にリストアップしてあります。
以下のクラスおよびインタフェースはSpring 2.0において削除されました。

  • ResultReader : RowMapperインタフェースを代わりに使用してください
  • BeanFactoryBootstrap : BeanFactoryLocatorもしくは自前のブートストラップクラスを使用することを考えてください。


2.7.1.5 Apache OJB
Apache OJBのサポートはSpringソースツリー上から完全に削除されてしまいました。Apache OJB統合ライブラリはいまだに入手可能ではありますが、それはSpring Modulesプロジェクトに移動しました。

2.7.1.6 iBATIS
iBATIS SQL Maps 1.3へのサポートは削除されました。iBATIS SQL Maps 2.3へ移行してください。

2.7.1.7 Hibernate
Hibernate 2.1と3.0へのサポートはバージョン2.5では削除されています。Hibernate 3.1以上に移行してください。
当面Hibernate 2.1もしくは3.0を使用しなければならない場合には、そのバージョンをサポートしているSpring 2.0.7/2.0.8を使用することをお勧めします。

2.7.1.8 JDO
JDO 1.0への対応は削除されました。JDO 2.0以上へ移行してください。
JDO 1.0を遣い続けなければならない場合には、やはりSpring 2.0.7/2.0.8を使用することをお勧めします。

2.7.1.9 UrlFilenameViewController
Spring 2.0から、UrlFilenameViewControllerによって決定されるビュー名はリクエストのネスとしたパスを考慮するようになりました。これはUrlFilenameViewControllerのもともとの規約からすると、大きな変更です。したがってこのクラスを使用するアプリケーションをSpring 1.xからSpring 2.xにアップグレードする際にはSpring Web MVCの設定を多少変更する必要が出てくるかもしれません。新しいビュー名決定の規約の具体例はこのクラスのJavadocに記述されていますので、参照してください。

原文:http://static.springframework.org/spring/docs/2.5.x/reference/new-in-2.html#new-in-2-migrating
ラベル:SpringFramework2.5

2008年06月24日

2.8. Updated sample applications

2.8 サンプルアプリケーションのアップデート
多くのサンプルアプリケーションも、Spring 2.0の新機能と変更点を紹介できるよう変更されています。ぜひサンプルを良く見てみる時間をとってください。サンプルアプリケーションはSpringの完全配布版(「spring-with-dependencies.[zip|tar.gz])の中の「sample」フォルダに配置されています。
Spring 2.5では改訂されたPetClinicとPetPortalが主要なサンプルアプリケーションとなっています。このサンプルでは徹底的にSpring 2.5で導入されたアノテーションによる設定をし使用して作られています。またJava 5のオートボクシングやジェネリクス、可変引数、拡張forループなどの機能も使用しています。サンプルのコンパイルと実行にはJava 5もしくは6のSDKが必要です。Spring 2.5の新機能を試すために、ぜひPetClinic/PetPortalをご覧になってください。

原文:http://static.springframework.org/spring/docs/2.5.x/reference/new-in-2.html#new-in-2-other-applications
ラベル:SpringFramework2.5

2.9. Improved documentation

2.9 ドキュメントの改善
Springのリファレンスはこれまで述べてきた新機能のすべてを反映するよう追記、修正がなされています。このドキュメント中に間違いがないよう細心の注意が払われていますが、なんらかの間違いが隠れているかもしれません。誤記やそのほかの間違いを発見した場合には、Springチームに課題を上げてください(訳注:この日本語訳に関するものはSpringチームに上げないでください)。
Spring FrameworkのリファレンスおよびJavadocの校正を精力的に行ってくれたArthur Loderに、この場で謝意を表します。

原文:http://static.springframework.org/spring/docs/2.5.x/reference/new-in-2.html#new-in-2-other-documentation
ラベル:SpringFramework2.5

2008年06月25日

I. Core Technologies

Springの主要技術
第一部ではこのリファレンスマニュアルの冒頭に扱うべき話題として、Spring Frameworkに不可欠な技術についてその全体像を明らかにします。
その中でも最も重要なものはIoC(Inversion of Control:制御の反転)コンテナでしょう。IoCコンテナについてそのすべてを解説したすぐ後には、アスペクト指向プログラミング(AOP)についてのわかりやすい解説を試みます。Spring FrameworkがもつAOPフレームワークの概念は理解しやすく、Javaによるエンタープライズ開発に必要なAOP機能のうち80%の重要な範囲をカバーしています。
またAspectJ(機能面からすれば現時点でもっとも優れており、またJavaのエンタープライズ領域においてもっとも成熟したAOP実装です)との統合機能も提供しています。
そして最後には、Springチームはテスト駆動開発(TDD:Test-Driven-Development)を採用することを推奨していますので、Springがサポートする統合テストについて(同時に単体テストのベストプラクティスについても)記述しています。単体テスト・結合テストはIoCコンテナを適切に使用することによって、かなり簡単になることをSpringチームは発見しました。つまりセッターメソッドと適切なコンストラクタさえあれば、テストの実行のためにわざわざサービスロケータレジストリをセットアップする必要がなくなるといった点において、手間を省くことができるのです。テストのためにまるまる一章を割きましたが、これを読んで読者の方にもそう思っていただければ幸いです。

  • 第三章 「IoCコンテナ」
  • 第四章 「リソース」
  • 第五章 「バリデーション、データバインディング、BeanWrapperとPropertyEditors」
  • 第六章 「Springでのアスペクト指向プログラミング」
  • 第七章 「Spring AOPのAPI」
  • 第八章 「テスト」


原文:http://static.springframework.org/spring/docs/2.5.x/reference/spring-core.html
ラベル:SpringFramework2.5

2008年06月26日

3.1. Introduction

3.1 はじめに
この章ではSpring FrameworkのIoCの実装について扱います。

Spring FrameworkのIoC(注1)コンテナの基本機能はorg.springframework.beansとorg.springframework.contextパッケージにて提供されています。BeanFactoryインタフェースは、どのような性質のオブジェクトでも管理できるような、一歩進んだ設定メカニズムを持っています。ApplicationContextインタフェースはBeanFactoryのサブインタフェースとして、SpringのAOP機能との統合、(国際化対応に使用される)メッセージリソースの管理、イベントプロパゲーション、アプリケーション層固有のコンテキスト(たとえばWebApplicationContext)などの追加機能を提供します。

つまり、BeanFactoryが設定のフレームワークと基本機能を担い、一方でApplicationContextがエンタープライズに必要な機能を追加提供するという形になっています。AppliccationContextはBeanFactoryの完全なスーパーセットなのでBeanFactoryの機能や挙動はApplicationContextにとってもまったく同じものであるといえます。

この章はBeanFactoryとApplicationContextのどちらにも適用されている基本的な原理について述べた前半と、ApplicationContextのみに当てはまる記述をしている後半部分に分かれています。


BeanFactoryとApplicationContext

ユーザは特定の状況においてBeanFactoryとApplicationFactoryのどちらを使用するのが適切であるか迷うような場合があります。BeanFactoryは単にBeanのインスタンス化と設定を行うものです。一方ApplicationContextはそういったことも行いますが、それに加えてエンタープライズアプリケーションに固有の多くの機能(AOPやトランザクションなど)に対応しています。
つまりApplicationContextを使用すれば良いということです。
(こう推奨する背景については、3.8.1 「BeanFactory or ApplicationContext?」を参照してください。)


注1:「背景」を参照してください。

原文:http://static.springframework.org/spring/docs/2.5.x/reference/beans.html#beans-introduction

2008年07月02日

3.2. Basics - containers and beans

3.2 IoCの基本−コンテナとBean
Springではアプリケーションの根幹を成し、Spring IoCコンテナによって管理されるオブジェクトをBeanと呼びます。BeanはSpring IoCコンテナによってインスタンス化され組み合わせられ、また管理されるオブジェクトであるというだけで、他に何も特別なことはありません(他に強いてあげるなら、あなたが関わっているアプリケーションを構成するクラスのうちのひとつである、ということくらいでしょうか)。これらのBeanとその間の依存性は、コンテナが使用する設定メタデータに反映されます。

原文:http://static.springframework.org/spring/docs/2.5.x/reference/beans.html#beans-basics
ラベル:SpringFramework2.5

3.2.1. The container

3.2.1 コンテナ
org.springframework.beans.factory.BeanFactoryは、前述のBeanを制御・管理するSpring IoCコンテナの実体をなすものです。

BeanFactoryインタフェースはIoCコンテナインタフェースの中心的なインタフェースです。このインタフェースの役割は、アプリケーションオブジェクトを生成・取得しそれを設定し依存関係を構築することです。

そのままで使用できるBeanFactoryインタフェースの実装が数多く提供されていますが、最も一般的に使用されるのはXmlBeanFactoryクラスでしょう。このクラスを使用することによって、アプリケーションを構成するオブジェクトの宣言と、そのオブジェクト間の依存関係をXMLによって設定することができます。XmlBeanFactoryはXMLによる設定メタデータ使用して全体の設定を行い、システムやアプリケーションを作り上げるのです。

[図:SpringのIoCコンテナ]


なぜBeanという名前を使うのか?

「コンポーネント」や「オブジェクト」を使用せずにわざわざ「Bean」という名前を採用した背景は、Spring Frameworkの起源に根ざしています(というのも、Spring Frameworkは複雑なEnterprise Java Bean に対するひとつの回答として作成されたという一面があるのです)。


3.2.1.1 設定メタデータ
上掲の図からもわかるように、SpringのIoCコンテナは設定メタデータを使用します。設定メタデータは単に、アプリケーション開発者がコンテナに「どのように(アプリケーション中のオブジェクトを)生成・設定・構築するか」を伝えるための手段です。通常この設定メタデータはシンプルでわかりやすいXMLによって提供されます。XMLによる設定メタデータを使用する場合には、IoCコンテナの管理下におきたいビーンのためのビーン定義を記述して、コンテナにその仕事をさせるだけです。

※注
XMLベースの設定は設定メタデータのなかでも最もよく使用される形式です。しかしこの形式だけしか使用できないわけではありません。Spring IoCコンテナはどんな形式で設定メタデータが書かれているかに縛られることなく使用することができます。XML形式の設定メタデータは非常にシンプルであるため、この章ではSpring IoCコンテナのキーとなる概念について、XMLを用いて紹介しています。
XML以外の形式でのSpringコンテナの設定については、3.11節 「アノテーションによる設定」を参照してください。


ほとんどのアプリケーション開発においては、Spring IoCコンテナのインスタンス化のためのコードを明示的に書く必要はありません。たとえばWebアプリケーション開発のほとんどのケースでは、8行程度のお決まりのJ2EEウェブデスクリプタXMLをアプリケーションで使用するweb.xmlファイルに書くだけで事足りてしまいます(3.8.5項 「ウェブアプリケーションのための簡便なApplicationContextのインスタンス化」を参照してください)。

Springの設定は管理対象となるビーンの定義を最低ひとつ持っています(複数になる場合がほとんどでしょう)。XMLを利用する場合にはこのビーン定義はトップレベルの<beans/>要素に囲まれた<bean/>要素によって設定されます。

ビーン定義はアプリケーションを構成する実際のオブジェクトに対応しています。ビーン定義は通常サービス層のオブジェクト、データアクセスオブジェクト(DAO)、StrutsのActionのようなプレゼンテーションオブジェクト、HibernateのSessionFactoryのような基盤オブジェクト、JMSのキューといったオブジェクトのために定義されます。一方、粒度の細かいドメインオブジェクトがコンテナ中で設定されることは稀です。なぜならドメインオブジェクトの保存やロードはDAOやビジネスロジックの責任範囲であるからです。

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"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">

<bean id="..." class="...">
<!-- collaborators and configuration for this bean go here -->
</bean>

<bean id="..." class="...">
<!-- collaborators and configuration for this bean go here -->
</bean>

<!-- more bean definitions go here -->

</beans>




リソース

ApplicationContextのコンストラクタに渡されるパスは、リソースの位置を示す文字列です。これによってコンテナはJavaのCLASSPATH以下にあるローカルファイルシステムなど、さまざまな外部リソースから設定メタデータを読み込むことができます。

Spring IoCコンテナについて理解したのちに、Springのリソースの概要についてより詳しく知りたい場合は第4章 「リソース」の記述を参照してください。


原文:http://static.springframework.org/spring/docs/2.5.x/reference/beans.html#beans-factory
ラベル:SpringFramework2.5

2008年07月04日

3.2.2. Instantiating a container

3.2.2 コンテナのインスタンス化
Spring IoCコンテナのインスタンス化手順はいたって単純です。

ApplicationContext context = new ClassPathXmlApplicationContext(
new String[] {"services.xml", "daos.xml"});

// an ApplicationContext is also a BeanFactory (via inheritance)
BeanFactory factory = context;


3.2.2.1 XMLによる設定メタデータを組み合わせる
コンテナ定義を複数のXMLファイルに分割して使用することは利益をもたらす場合があります。複数ファイルに分割されたApplicationContextをロードする際には、複数のリソースパスを受け取るApplicationContextのコンストラクタを使用します。BeanFactoryは複数のビーン定義を順に読み込んでいきます。

一般的な場合にはこの方法を使用することをお勧めします。なぜかといえばコンテナ設定ファイルから、他のファイルとの関連を取り除くことができるからです。しかしながら<import/>要素をひとつまたは複数使用することで他のファイルからビーン定義を読み込むこともできます。以下がサンプルです。


<beans>

<import resource="services.xml"/>
<import resource="resources/messageSource.xml"/>
<import resource="/resources/themeSource.xml"/>

<bean id="bean1" class="..."/>
<bean id="bean2" class="..."/>

</beans>


この例では3つの外部ファイル(services.xml、messageSource.xml、themeSource.xml)からビーン定義が読み込まれています。これらのファイルの場所は、インポートを記述しているファイルからの相対パスと解釈されます。したがってこのケースではservices.xmlではこのファイルと同じディレクトリになければならず、またmessageSource.xmlとthemeSource.xmlはこのファイルがあるディレクトリ以下のresourcesディレクトリの中に配置されていなければなりません。先頭のスラッシュは無視されますが、相対パスとして扱われることを表すことができるため、スラッシュを使用しないよりはベターな形式かもしれません。インポートされるファイルはSpringのスキーマもしくはDTDに準拠した妥当なXMLによる(トップレベル要素として<:bean/%gt;要素を持った)ビーン定義ファイルでなければなりません。
※注
相対パスにおいて「../」を使用して親ディレクトリを参照させることは可能ですが、アプリケーションの外側のファイルに依存することになるため推奨されていません。特に「classpath:」URL(たとえば「classpath:../services.xml」)は実行時のパス解決が「最も近い」クラスパスルートを使用して親ディレクトリを参照しようとするためお勧めできません。これはクラスパスの変更によって今までと異なるディレクトリが使用される可能性があり、ひ弱なアプリケーションになってしまいます。
また相対ではなく絶対パスによる指定(たとえば「file:C:/config/services.xml」や「classpath:/config/services.html」)をすることもできますが、その場合にはアプリケーションの設定ファイルがその特定のパスに固定されてしまうことに注意してください。一般的には、たとえば実行時のJVMのシステムプロパティーによって解決される「${...}」プレースホルダを使用するなど、絶対パスを使用する際には何らかの対応をするほうが良いでしょう。



原文:http://static.springframework.org/spring/docs/2.5.x/reference/beans.html#beans-factory-instantiation

2008年08月31日

3.2.3 Bean

Spring IoCコンテナは複数の「bean」を管理します。Beanはコンテナに与えられた(通常はXMLの<bean/>で定義される)設定メタデータを使用して生成されます。
コンテナ内部ではこの設定データは BeanDefinition オブジェクトとして保持されています。BeanDefinitionオブジェクトは主に以下のような情報を保持しています:

  • 完全修飾クラス名:実際に使用されるbean実装クラスの名前
  • Beanの振る舞いの設定情報(スコープやライフサイクルにおけるコールバックなど)
  • このbeanの処理に必要な他のbeanへの参照(こうしたbeanはコラボレータあるいは依存と呼ばれるものです)。
  • そのほか生成されたオブジェクトに設定される値。たとえばbeanが使用するコネクションプールが管理するコネクション数やその上限など。

上述の概念は、bean定義を構成するプロパティーに直接結びついています。これらのプロパティのうちのいくつかをその項目の解説へのリンクとともに以下に掲載します。
table 3.1 Bean定義
項目解説している章
クラス3.2.3.2 Beanのインスタンス化
命名3.2.3.1 Beanの命名
スコープ3.4 Beanのスコープ
コンストラクタの引数3.3.1 依存性の注入
プロパティ3.3.1 依存性の注入
自動ワイヤリングモード3.3.5 コラボレータの自動ワイヤリング
依存性チェックモード3.3.6 依存性をチェックする
遅延初期化モード3.3.4 Beanの遅延初期化
初期化メソッド3.5.1.1 初期化コールバック
破棄メソッド3.5.1.2 破棄コールバック


特定のbeanを生成するための情報をもつbean定義に加えて、ファクトリ外で(ユーザコードによって)生成されたオブジェクトを後から登録できるようになっているBeanFactory実装もあります。DefaultListableBeanFactoryクラスはregisterSingleton(..)メソッドにてこの機能をサポートしています。(しかし通常はメタデータによるBean定義のみで動作させることができます。)

原文:http://static.springframework.org/spring/docs/2.5.x/reference/beans.html#beans-definition

2008年09月01日

3.2.3.1 Naming Beans

3.2.3.1 Beanの命名
すべてのbeanは1つもしくは複数のID(識別子あるいは単に名前とも呼びますが同じ意味です)を持っています。これらのIDはひとつのそれを使用するコンテナ内でユニークでなければなりません。ほとんどの場合においてひとつのbeanはひとつのIDを持ちますが、複数のIDを持つ場合には2つ目以降のIDはエイリアスであるとみなされます。

XMLによる設定を使用する場合であれば、「id」属性もしくは「name」属性によってbeanのIDを指定することができます。「id」属性は1つのIDのみを指定することができます。

「id」属性はXMLにおいても要素が持つ属性として定義されているので、XMLパーサが他の要素からの参照についてバリデーションを行うことができます。そのためIDの指定にはこの方法を推奨しています。しかしXMLの使用ではXMLのID属性として使用可能な文字を限定しています。多くの場合においてこれは制約とはならないでしょうが、これに反する特殊文字を使用する必要がある場合には「name」属性を使用してください。またID以外のエイリアスを導入する場合にも「name」属性を使用します。「id」属性と同時に使用することもできますし、「id」属性を省略して代わりに使用することもできます。また複数のIDを指定する場合にはカンマ(,)かセミコロン(;)または半角空白で区切って指定することができます。

Beanに名前をつけることは必須ではありません。名前が明示されない場合にはコンテナはユニークな名前を生成して使用します。Beanに名前をつけない意味については後ほど述べます(ひとつの例としては「3.3.2.3 内部ビーン」が挙げられます)。

Beanの命名規約
Beanの(少なくともSpring開発チーム内で使用されている)命名規約は標準的なJavaの規約のインスタンスフィールドと同じものです。つまり小文字で始まり以降はキャメルケースとなります。具体例を挙げれば「accountManager」や「accountService」、「userDao」、「loginController」といったような形になります。
一貫した命名法を使用することによって、長期間にわたって設定の可読性をあげ理解しやすいものにすることができます。こうした規約を採用することは困難なことではありませんし、Spring AOPを使用する場合にbeanの命名に適用することですぐにそれ以上の利益が得られるでしょう。


3.2.3.1.1 Beanにエイリアスをつける
Bean定義中に「id」属性にひとつまで、「name」属性にひとつ以上の名前を指定することで、beanに対してひとつ以上の名前をつけることができます。これらの名前は、どれもひとつのbeanに対するエイリアスであるとみなされます。これはアプリケーションで使用される各コンポーネントにおいて、そのコンポーネント固有の名前で共通のbeanを参照する際などの場合に価値を発揮します。

しかしbeanを定義するときにすべてのエイリアスを指定することが適切でない場合もあります。どこか別の場所で定義されたbeanに対してエイリアスをつけることが望ましいこともあるでしょう。XMLによる設定ファイル中では<alias/>要素を使用することによってこれを実現することができます。

<alias name="fromName" alias="toName"/>


このケースでは「fromName」と名付けられたbeanを、同一コンテナ内であればこの定義以降「toName」という名前でも参照することができるようになります。

具体例を挙げてみましょう。AというコンポーネントがそのXML設定の中で「componentA-dataSource」というDataSource beanを定義しているとします。BというコンポーネントではそのDataSource beanを「componentB-dataSource」というなでXML設定から参照しようとしています。そしてMyAppというメインのアプリケーションはその設定中で上記の3つの設定からアプリケーションコンテキストを組み立て、DateSourceを「myApp-dataSource」として参照したいというケースです。この場合にはMyAppの設定部分で以下のalias要素を追加するだけで目的を達成できます:

<alias name="componentA-dataSource" alias="componentB-dataSource"/>
<alias name="componentA-dataSource" alias="myApp-dataSource">


こうすることでA、B二つのコンポーネントとメインアプリケーションから同じビーンを参照しているにも関わらず、ユニークで他コンポーネントの定義に干渉しないことが保障された名前を使用することができるようになります(事実上ネームスペースがあるのと同じです)。


原文:http://static.springframework.org/spring/docs/2.5.x/reference/beans.html#beans-beanname

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

この広告は1年以上新しい記事の投稿がないブログに表示されております。