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

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年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年07月02日

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

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

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年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

2008年06月24日

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

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

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

広告


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

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

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


×

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