Seam はエンタープライズ Java 向けのアプリケーションフレームワークです。以下のような理念に基づいています。
Seam はアプリケーションのすべてのビジネスロジックのために一貫したコンポーネントモデルを定義します。Seam コンポーネントは、明確に定義された数種類のコンテキストの一つに関係付けられた状態を持つステートフルなものであるかもしれません。これらのコンテキストには、長時間に渡って実行され永続化される ビジネスプロセスコンテキスト や、複数の Web 要求にまたがる一連のユーザーインタラクション間で保持される 対話コンテキスト (conversation context) が含まれます。
Seam ではプレゼンテーション層コンポーネントとビジネスロジック層コンポーネントとに区別はありません。アプリケーションを自分で工夫したどんなアーキテクチャにも階層化することができます。今日使用している煙突型(スタック型)フレームワークのいかなる組み合わせによっても要求される不自然な階層化構造に、アプリケーションロジックを詰め込むようなことは強制されません。
Unlike plain Java EE or J2EE components, Seam components may simultaneously access state associated with the web request and state held in transactional resources (without the need to propagate web request state manually via method parameters). You might object that the application layering imposed upon you by the old J2EE platform was a Good Thing. Well, nothing stops you creating an equivalent layered architecture using Seam—the difference is that you get to architect your own application and decide what the layers are and how they work together.
JSF と EJB 3.0 は、Java EE 5 の最も素晴らしい二つの新機能です。EJB3 は、サーバサイドのビジネスロジックと永続化ロジックのための全く新しいコンポーネントモデルです。一方、JSF はプレゼンテーション層のための優れたコンポーネントモデルです。残念なことに、どちらのコンポーネントモデルも片方だけではすべてのコンピューティング問題を解決することはできません。その代わりに、JSF と EJB3 を一緒に使用すれば最も良く働かせることができます。しかし、Java EE 5 仕様では、二つのコンポーネントモデルを統合するための標準的な方法を提供していません。幸いにも、両方のモデルの策定者はこの状況を予見していて、モデルを拡張したり他のフレームワークと統合したりを可能にするための標準拡張ポイントを提供しています。
Seam は JSFと EJB3 のコンポーネントモデルを統一し、 コンポーネント間の接着剤としてのコード (glue code) を取り除き、開発者がビジネス関連の問題解決に重点を置けるようにしてくれます。
It is possible to write Seam applications where "everything" is an EJB. This may come as a surprise if you're used to thinking of EJBs as coarse-grained, so-called "heavyweight" objects. However, version 3.0 has completely changed the nature of EJB from the point of view of the developer. An EJB is a fine-grained object—nothing more complex than an annotated JavaBean. Seam even encourages you to use session beans as JSF action listeners!
一方で、もし現時点では EJB 3.0 を採用しない方を好めば、EJB 3.0 を使用する必要はありません。事実上はどんな Java クラスでも、Seam コンポーネントになることができます。さらに Seam は、EJB であろうとなかろうといかなるコンポーネントに対しても、「軽量 (lightweight)」コンテナに期待されるすべての機能を提供します。
Seamは、最も素晴らしいオープンソースの JSF ベース AJAX ソリューションであるJBoss RichFaces と ICEfaces をサポートします。これらのソリューションは、一切 JavaScript コードを記述する必要なしに、ユーザーインタフェースに AJAX 機能を追加させることができます。
もう一つの方法として、Seam は組み込みの JavaScript リモーティング層を提供していて、中間のアクションレイヤを必要とせずに、クライアント側の JavaScript から非同期にコンポーネントと呼び出すことができます。サーバ側の JMS トピックをサブスクライブして、AJAX プッシュによってメッセージを受信することもできます。
これらのアプローチのどちらも、Seam の組み込みの並行処理制御や状態管理に対してのものではないので、それらの機能に対してはうまく動作しません。しかし、並列に実行される多くの細粒度の非同期の AJAX 要求がサーバサイドで安全にそして効率的に処理されるということを保証します。
オプションとして、Seam は jBPM による透過的なビジネスプロセス管理を提供します。jBPM と Seam を利用した複雑なワークフロー、コラボレーション、タスク管理の実装がいかに簡単であるか信じられないことでしょう。
Seam は、jBPM がビジネスプロセス定義に使用するのと同じ言語 (jPDL) をプレゼンテーション層のページフローの定義にも利用することを可能にします。
JSFは、プレゼンテーション層のために信じられないほど豊富なイベントモデルを提供します。Seam の一貫したコンポーネントモデルに対して一貫したイベントモデルを提供することにより、Seam は全く同様のイベント処理メカニズムを jBPM のビジネスプロセス関連イベントにも適用するによってこのモデルを改良します。
EJB は初期の頃から、宣言的なトランザクション管理と宣言的なセキュリティのコンセプトを採用しています。EJB 3.0 では、宣言的な永続コンテキスト管理さえも導入します。これら三つは、特定のコンテキストに関連付けられたより広範囲での状態管理の問題の例で、コンテキストが終わるときには、それらはすべての確実に破棄することが必要となります。Seamは、宣言的な状態管理のコンセプトをはるかに広くとらえて、アプリケーション状態にもそれを適用します。伝統的にJ2EE アプリケーションでは、サーブレットセッションと要求属性を 保存 (set) そして取得 (get) することによって、状態管理を手動で実装します。状態管理に対するこの手法は、アプリケーションがセッション属性をきれいにし損ねたり、あるいは異なるワークフローに関連したセッションデータがマルチウィンドウのアプリケーションで衝突したりしたときに、多くのバグとメモリリークの発生源となります。Seam には、この種類のバグをほとんど完全に削除できる潜在能力があります。
Declarative application state management is made possible by the richness of the context model defined by Seam. Seam extends the context model defined by the servlet spec—request, session, application—with two new contexts—conversation and business process—that are more meaningful from the point of view of the business logic.
対話コンテキストを利用し始めると、いかに多くのことがより簡単になるか驚かされるでしょう。Hibernate あるいは JPA のような ORM ソリューションで遅延関連フェッチを利用して、障害を経験したことがありませんか。 Seam の対話スコープ永続コンテキストを使用すると、めったに LazyInitializationException
を見ることがなくなるということになります。リフレッシュボタンで問題が発生したことがありませんか。 戻るボタンで問題が発生したことがありませんか。送信フォームの二重送信で問題が発生したことがありませんか。post-then-redirect をまたがったメッセージ引継ぎで問題が発生したことがありませんか。Seam の対話管理は、これらの問題を個別に考える必要なしに解決します。これらはすべて、Web の最も初期の頃以来蔓延している中途半端な状態管理アーキテクチャが原因の症状なのです。
制御の反転 (IoC: Inversion of Control) あるいは 依存性注入 (DI: Dependency Injection) の概念は、多くのいわゆる「軽量コンテナ」と同様に、JSF と EJB3 の両方に存在します。これらのコンテナのほとんどは、ステートレスなサービス を実装するコンポーネントのインジェクションに力点が置かれています。たとえステートフルなコンポーネントのインジェクションがサポートされたとしても (例えば JSF において)、アプリケーション状態を扱う場合においては事実上役に立ちません。なぜならば、ステートフルなコンポーネントのスコープが十分な柔軟性を持って定義されていないので、より広いスコープに属しているコンポーネントをより狭いスコープに属するコンポーネントへインジェクションすることができないからです。
バイジェクション (bijection) は、それが動的 (dynamic) であり、コンテキスト依存 (contextual) であり、そして双方向的 (bidirectional) であるという点で IoC とは異なります。コンテキスト上の変数(現在のスレッドにバインドされたさまざまなコンテキストでの名前)をコンポーネントの属性に別名でアクセスするためのメカニズムだと考えることができます。バイジェクションは、コンテナによるステートフルなコンポーネントを自動的に組み立てることを可能にします。それはコンポーネントの属性に値を代入するだけで、コンポーネントが安全にそして簡単にコンテキスト変数の値を操作することを可能にします。
Seam アプリケーションは、それぞれが別々の安全に分離された対話に関連付けられた複数のブラウザタブ間を、ユーザーが自由にスイッチすることを可能にします。アプリケーションは、さらにワークスペース管理を利用して、一つのブラウザタブ内で対話 (ワークスペース) の間をユーザーが切り替えることも可能にします。Seam は、正しいマルチウィンドウの操作のみを提供するのではなく、一つのウィンドウ内でのマルチウィンドウ風の操作も提供するのです
伝統的にJavaコミュニティは、どのような種類のメタ情報が構成として重要かについて深い混乱の状態にいました。J2EE と人気がある 「軽量」のコンテナは、XML ベースのデプロイメント記述子を提供し、異なるシステム間でのデプロイの構成を共通化するとともに、Java では簡単に表現できないその他の宣言を可能にしました。Java 5 のアノテーションがこのすべてを変えました。
EJB 3.0 は、 宣言的な形式でコンテナに情報を提供する最も簡単な方法としてアノテーションと「例外による設定 (configuration by exception)」を採用しています。 残念ながら、 JSF はまだ冗長な XML 設定ファイルに大きく依存しています。 Seam は、 EJB 3.0 によって提供されるアノテーションに宣言的状態管理および宣言的コンテキスト区分用のアノテーション一式を提供することにより機能拡張しています。 これにより、 うっとうしい JSF 管理Beanの宣言を取り除き、 必要とされる XML を減少させ、本当に XML で定義すべき情報 (JSF ナビゲーション規則) だけになるようにします。
Seam コンポーネントは、単純な Java クラスであって、本来ユニットテストで十分テストできるものです。しかし複雑なアプリケーションでは、ユニットテストだけは不十分です。伝統的にJava の Web アプリケーションにおいては、結合テストは繁雑で困難な作業でした。それゆえに、Seam はフレームワークのコア機能として、Seam アプリケーションのテスト機能を提供します。システムのすべてのコンポーネントをビュー (JSP ページまたは Facelets ページ)から切り離して動作させることにより、ユーザーとのすべての相互作用を再現する JUnit あるいは TestNG のテストを簡単に記述することができます。これらのテストを直接 IDE の内部で実行することができます。そこでは、Seam が 組み込み型 JBoss を利用して EJB コンポーネントを自動的にデプロイします。
Java EEの最新の実装は素晴らしいと思います。しかし、それが決して完全ではないということも知っています。どの仕様にも欠点はあるので(例えば、GET 要求における JSF ライフサイクルの制限)、Seam はそれを修正します。Seam の作者らは、JCP エキスパートグループと一緒に活動していて、それらの修正が標準仕様の次の改訂版に確実に反映されるようにしています。
今日の Web フレームワークは、あまりにも小さく考え過ぎます。Web フレームワークは、フォームからユーザー入力を取り出し、Java のオブジェクトへ代入します。そしてそのままにしておきます。本当に完全な Web アプリケーションフレームワークは、永続化、並行処理、非同期処理、状態管理、セキュリティ、Eメール、メッセージング、PDFとチャートの生成、ワークフロー、してwiki テキスト、Web サービス、キャッシングその他多数の問題を処理すべきです。一旦 Seam を使用してみれば、いかに多くの問題がより簡単になることに驚くでしょう...
Seamは、永続化のために JPA や Hibernate3 を統合します。軽量な非同期処理のためには EJB タイマサービスや Quartz、ワークフローのために jBPM、ビジネスルールのために JBoss Rules、Eメールのために Meldware Mail、 フルテキスト検索のために Hibernate Search や Lucene、メッセージングのために JMS、ページフラグメントキャッシュのために JBoss Cache を統合します。Seam は、JAAS とJBoss Rules を連携した革新的なルールベースのセキュリティフレームワーク層を提供します。さらに、PDF レンダリングやメール送信、チャート、wiki テキスト のための JSF タグライブラリもあります。Seam コンポーネントは、Web サービスとして同期的に呼び出すことができます。クライアント側の JavaScript あるいは Google Web Toolkit 、またもちろん直接 JSF から非同期的に呼び出すことができます。
Seam は、どの Java EE アプリケーションサーバーでも動作します。さらに、Tomcat でさえも動作します。もしあなたの環境が EJB 3.0 をサポートしているのであれば、すばらしい完璧です!もしサポートしていなくても、問題ありません。永続化のための JPA あるいは Hibernate3 と Seam の組み込みトランザクション管理を使用することができます。あるいは、Tomcat に組み込み型 JBoss をデプロイして、EJB 3.0 に対するフルサポートを受けることもできます。
Seam と JSF と EJB3 の組み合わせが Java で複雑な Web アプリケーションを記述する最もシンプルな方法であることが明らかになります。必要となるコードが信じられないほど少なくなるのです。
Seam に貢献して頂ける方は SeamFramework.org をご覧ください。
Seam は Seam のさまざまな機能の利用方法を実演する多くのサンプルアプリケーションを提供しています。 このチュートリアルはこれらのサンプルを通してあなたが Seam を学び始めるための案内をします。Seam サンプルは Seam ディストリビューションの examples
サブディレクトリに置かれています。 初めて見るユーザー登録サンプルは、examples/registration
ディレクトリにあります。
各サンプルは同じディレクトリの構造をしています。
The view
ディレクトリにはWebページテンプレート、イメージ、スタイルシートなどビュー関連のファイルが入っています。
resources
ディレクトリにはデプロイメント記述子やその他の構成ファイルが入っています。
src
ディレクトリにはアプリケーションソースコードが入っています。
サンプルアプリケーションは追加設定することなく JBoss AS と Tomcat で動作します。 これからの章では両方のケースの手順を説明します。 Ant build.xml
によりビルドと起動を行いますから、始める前に最新の Ant をインストールする必要があることに留意してください。
The examples are configured for use on JBoss 4.2. You'll need to set jboss.home
, in the shared build.properties
file in the root folder of your Seam installation, to the location of your JBoss AS installation .
Once you've done that and started the application server, you can build and deploy any example by typing ant deploy
in the the directory for that example. The examples all deploy to a URL like /seam-
. For the registration example, the URL would be example
http://localhost:8080/seam-registration/
.
サンプルは Tomcat 6.0 用にも構成されています。Tomcat 6.0 組み込み JBossへのインストールは 項29.6.1. 「Embedded JBoss をインストールする」 のインストラクションに従う必要があります。 組み込み JBoss は Tomcat 上で EJB3コンポーネントを利用する Seam デモを動作させるためだけに必要です。 組み込み JBoss を利用しない Tomcat 上で動作可能な non-EJB3 サンプルもあります。
Seam のインストレーションのルートフォルダ内 build.properties
ファイル中の tomcat.home
に Tomcat のインストレーションの場所を設定する必要があります。 Tomcat の場所を設定したことを確かめてください。
Tomcat を利用する場合には異なった Ant ターゲットを使用する必要があります。 Tomcat 用のサンプルのビルドとデプロイで example サブディレクトリ内の ant tomcat.deploy
を使用してください。
On Tomcat, the examples deploy to URLs like /jboss-seam-
, so for the registration example the URL would be example
http://localhost:8080/jboss-seam-registration/
.
ユーザー登録サンプルはデータベースに新規ユーザーのユーザー名、 実名、 パスワードをデータベースに保存できる簡単なアプリケーションです。 このサンプルでは Seam の高度な機能のすべてを見せることはできませんが、 JSF アクションリスナーとして EJB3 セッション Bean を使用する方法や、 基本的な Seam の設定方法を見せてくれます。
EJB 3.0 にまだ不慣れな方もいらっしゃるかもしれませんので、 ゆっくり進めていきます。
最初のページは三つの入力フィールドを持つ基本的なフォームを表示します。 試しに、項目を入力してフォームをサブミットしてください。 これでユーザーオブジェクトはデータベースに保存されます。
このサンプルは、二つの Facelets テンプレート、一つのエンティティ Bean と、一つのステートレスセッション Bean で実装されています。 "bottom" からコードを見てみましょう。
ユーザーデータのために、EJBエンティティ Beanが必要です。 このクラスでは、アノテーションによって 永続性 と データ妥当性検証 を宣言的に定義しています。 Seam コンポーネントとしてのクラスを定義するために、別にいくつかのアノテーションも必要です。
例 1.1. User.java
@Entity
@Name("user")
@Scope(SESSION)
@Table(name="users")
public class User implements Serializable
{
private static final long serialVersionUID = 1881413500711441951L;
private String username;
private String password;
private String name;
public User(String name, String password, String username)
{
this.name = name;
this.password = password;
this.username = username;
}
public User() {}
@NotNull @Length(min=5, max=15)
public String getPassword()
{
return password;
}
public void setPassword(String password)
{
this.password = password;
}
@NotNull
public String getName()
{
return name;
}
public void setName(String name)
{
this.name = name;
}
@Id @NotNull @Length(min=5, max=15)
public String getUsername()
{
return username;
}
public void setUsername(String username)
{
this.username = username;
}
}
![]() | EJB3 標準 |
![]() | Seam コンポーネントは |
![]() | Seam がコンポーネントをインスタンス化する時には、 必ずコンポーネントの デフォルトコンテキストにあるコンテキスト変数に新しいインスタンスをバインドします。 デフォルトコンテキストは |
![]() | EJB 標準 |
![]() |
|
![]() | 空コンストラクタは、EJB と Seam の両方の仕様から必要となります。 |
![]() |
|
![]() | EJB 標準 |
このサンプルで、もっとも注目してほしい重要なものは @Name
と @Scope
アノテーションです。 このアノテーションは、このクラスが Seam コンポーネントであることを規定しています。
以下では、User
クラスのプロパティは 直接 JSF コンポーネントにバインドされ、 モデル値の変更フェーズで JSF によって生成されたことがわかります。 JSP ページとエンティティ Bean ドメインモデル間を行き来するデータコピーの面倒なコードは必要ありません。
しかし、 エンティティ Bean はトランザクション管理やデータベースアクセスを行わないので、 このコンポーネントを JSF のアクションリスナーとしては使用できません。 このため、 セッション Bean が必要となります。
ほとんどの Seam アプリケーションは、セッション Bean を JSF アクションリスナーとして使用します。 (好みに応じて JavaBean を使うことも可能)
アプリケーション内の JSF アクションはちょうど一つだけで、 これにセッションBean メソッドが 一つリンクしています。 このサンプルでは、 アクションに関連する状態はすべて User
Bean によって保持されるため、 ステートレスセッション Bean を使用しています。
サンプルの中で、本当に注意すべきコードは以下のみです。
例 1.2. RegisterAction.java
@Stateless@Name("register") public class RegisterAction implements Register { @In
private User user; @Persistenc
eContext private EntityManager em; @Logger
private Log log; public Stri
ng register() { List existing = em.createQuery( "sele
ct username from User where username=#{user.username}") .getResultList(); if (existing.size()==0) { em.persist(user); log.i
nfo("Registered new user #{user.username}"); retur
n "/registered.xhtml"; } else { Faces
Messages.instance().add("User #{user.username} already exists"); return null; } } }
![]() | EJB |
![]() | |
![]() | EJB 標準 |
![]() | Seam |
![]() | アクションリスナーメソッドは、データベースとやり取りするために、 標準 EJB3 |
![]() | Seam では EJB-QL 内で JSF EL 式を使用することができます。 バックグラウンドで行われるため見えませんが、 これにより普通の JPA |
![]() | The |
![]() | JSF アクションリスナーメソッドは、次にどのページを表示するかを決定するストリング値の結果 (outcome) を返します。 null 結果 (outcome) (あるいは、void アクションリスナーメソッド) は、 前のページを再表示します。 普通の JSF では、 結果 (outcome) から JSF ビュー id を決定するために、 常に JSF ナビゲーション規則 を使用することが普通です。 複雑なアプリケーションにとって、この間接的方法は、実用的な良い慣行です。 しかし、このようなとても簡単なサンプルのために、 Seam は、結果 (outcome) として JSF ビュー id の使用を可能とし、 ナビゲーション規則の必要性を取り除きました。 結果 (outcome) としてビュー id を使用する場合、 Seam は、常にブラウザリダイレクトを行うことに留意してください。 |
![]() | Seam provides a number of built-in components to help solve common problems. The |
ここで、@Scope
を明示的に指定していないことに留意してください。 各 Seam コンポーネントタイプは明示的にスコープが指定されない場合デフォルトのスコープが適用されます。 ステートレスセッション Bean のデフォルトスコープはステートレスコンテキストです。 これは単に理にかなった値です。
このセッション Bean のアクションリスナーは、この小さなアプリケーションのビジネスロジックと永続ロジックを提供しています。 さらに複雑なアプリケーションでは、個別のサービスレイヤが必要かもしれません。 Seamで、これをするのは簡単ですが、 ほとんどの Web アプリケーションでは過剰です。 Seam は、アプリケーションのレイヤ化のために特殊な方法を強要しているのではなく、アプリケーションをより簡単に、また望むならばより複雑にすることを可能にしています。
このアプリケーションについて、私たちはこれまで実際に必要とされるよりはるかに複雑にしてきました。 Seam アプリケーションコントローラを利用していたならば、アプリケーションコードのほとんどを排除できたかもしれない。しかしながら、 当時、説明する多くのアプリケーションがありませんでした。
当然、セッション Bean には、ローカルインタフェースが必要です。
Java コードは以上です。 次は ビューを見ましょう。
Seam アプリケーションのビューページは、 JSF をサポートする多くの技術を使用して実装されています。 このサンプルでは、JSP より優れていると考えている Facelets を使用しています。
例 1.4. register.xhtml
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:s="http://jboss.com/products/seam/taglib"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core">
<head>
<title
>Register New User</title>
</head>
<body>
<f:view>
<h:form>
<s:validateAll>
<h:panelGrid columns="2">
Username: <h:inputText value="#{user.username}" required="true"/>
Real Name: <h:inputText value="#{user.name}" required="true"/>
Password: <h:inputSecret value="#{user.password}" required="true"/>
</h:panelGrid>
</s:validateAll>
<h:messages/>
<h:commandButton value="Register" action="#{register.register}"/>
</h:form>
</f:view>
</body>
</html
>
ここで Seam 固有となるのは <s:validateAll>
タグのみです。 この JSF コンポーネントは 含まれるすべての入力フィールドをエンティティ Bean で指定される Hibernate Validator アノテーションに対して検証するよう JSF に指示しています。
例 1.5. registered.xhtml
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://java.sun.com/jsf/core">
<head>
<title
>Successfully Registered New User</title>
</head>
<body>
<f:view>
Welcome, #{user.name}, you are successfully registered as #{user.username}.
</f:view>
</body>
</html>
This is a simple Facelets page using some embedded EL. There is nothing specific to Seam here.
はじめて Seam アプリを見るので、デプロイメント記述子も見てみます。 その話の前に、Seam が最小限の設定であることは注目に値します。 これらの設定ファイルは、Seamアプリケーションが作成されるときに生成されるものです。 あなたはほとんどこれらのファイルに触れる必要はないでしょう。 サンプルにおいてすべての要素が何をしているかを理解すること助けるためだけにこれらを提示しています。
既に多くの Java フレームワークを使用した経験がある方なら、 プロジェクトが成熟するにつれ徐々に大きくなり管理し難くなる XML ファイルにコンポーネントクラスをすべてを宣言することにもそのうち慣れていくことでしょう。 Seam ではアプリケーションコンポーネントに XML を付随する必要がないこと知ったら、 きっとほっとすることでしょう。 大部分の Seam アプリケーションは、ほんの少しの XML しか必要としません。 また、 この XMLはプロジェクトが大きくなっていっても、 あまり大きくなりません。
それにもかかわらず、あるコンポーネントのある外部設定の規定が可能であることは、 多くの場合、有用です (特に、Seam に組み込まれたコンポーネント)。 ここでは二つの選択があります。 しかし、最も柔軟性のある選択は WEB-INF
ディレクトリに位置する components.xml
と呼ばれるファイルに設定を規定することです。 Seam に JNDI で EJB コンポーネントの見つけ方を指示するためには components.xml
ファイルを使用します。
例 1.6. components.xml
<?xml version="1.0" encoding="UTF-8"?>
<components xmlns="http://jboss.com/products/seam/components"
xmlns:core="http://jboss.com/products/seam/core"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<core:init jndi-pattern="@jndiPattern@"/>
</components
>
This code configures a property named jndiPattern
of a built-in Seam component named org.jboss.seam.core.init
. The funny @
symbols are there because our Ant build script puts the correct JNDI pattern in when we deploy the application.
ミニアプリケーションのプレゼンテーションレイヤは WAR にデプロイされます。 したがって、Web デプロイメント記述子が必要です。
例 1.7. web.xml
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
<!-- Seam -->
<listener>
<listener-class
>org.jboss.seam.servlet.SeamListener</listener-class>
</listener>
<!-- JSF -->
<listener>
<listener-class
>com.sun.faces.config.ConfigureListener</listener-class>
</listener>
<context-param>
<param-name
>javax.faces.DEFAULT_SUFFIX</param-name>
<param-value
>.xhtml</param-value>
</context-param>
<servlet>
<servlet-name
>Faces Servlet</servlet-name>
<servlet-class
>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup
>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name
>Faces Servlet</servlet-name>
<url-pattern
>*.seam</url-pattern>
</servlet-mapping>
<session-config>
<session-timeout
>10</session-timeout>
</session-config>
</web-app
>
この web.xml
ファイルは Seam と JSF を設定します。 ここで見る設定は Seam アプリケーションではいつも同じです。
ほとんどの Seam アプリケーションはプレゼンテーション層として JSF ビューを使用します。 従って通常 faces-config.xml
が必要です。 この場合ビュー定義に Facelets を使用しますので、JSF にテンプレートエンジンとして Faceles を使用することを指定する必要があります。
例 1.8. faces-config.xml
<?xml version="1.0" encoding="UTF-8"?>
<faces-config version="1.2"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd">
<!-- Facelets support -->
<application>
<view-handler
>com.sun.facelets.FaceletViewHandler</view-handler>
</application>
</faces-config
>
Note that we don't need any JSF managed bean declarations! Our managed beans are annotated Seam components. In Seam applications, the faces-config.xml
is used much less often than in plain JSF.
In fact, once you have all the basic descriptors set up, the only XML you need to write as you add new functionality to a Seam application is orchestration: navigation rules or jBPM process definitions. Seam takes the view that process flow and configuration data are the only things that truly belong in XML.
この簡単なサンプルでは、 ビュー id をアクションコードに埋め込んだため、 ナビゲーション規則さえ不要です。
ejb-jar.xml
ファイルは、 アーカイブ中のすべてのセッション Bean に SeamInterceptor
を付加することによって EJB3 と統合します。
<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"
version="3.0">
<interceptors>
<interceptor>
<interceptor-class
>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
</interceptor>
</interceptors>
<assembly-descriptor>
<interceptor-binding>
<ejb-name
>*</ejb-name>
<interceptor-class
>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
</interceptor-binding>
</assembly-descriptor>
</ejb-jar
>
persistence.xml
ファイルは、EJB 永続プロバイダに、 データソースの場所を指示します。また、ベンダー固有の設定を含んでいます。 このサンプルでは起動時に自動スキーマエキスポートを可能としています。
<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
version="1.0">
<persistence-unit name="userDatabase">
<provider
>org.hibernate.ejb.HibernatePersistence</provider>
<jta-data-source
>java:/DefaultDS</jta-data-source>
<properties>
<property name="hibernate.hbm2ddl.auto" value="create-drop"/>
</properties>
</persistence-unit>
</persistence
>
最後に、EARとして アプリケーションがデプロイされるため、デプロイメント記述子も必要になります。
例 1.9. ユーザー登録アプリケーション
<?xml version="1.0" encoding="UTF-8"?>
<application xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/application_5.xsd"
version="5">
<display-name
>Seam Registration</display-name>
<module>
<web>
<web-uri
>jboss-seam-registration.war</web-uri>
<context-root
>/seam-registration</context-root>
</web>
</module>
<module>
<ejb
>jboss-seam-registration.jar</ejb>
</module>
<module>
<ejb
>jboss-seam.jar</ejb>
</module>
<module>
<java
>jboss-el.jar</java>
</module>
</application
>
このデプロイメント記述子はエンタープライズアーカイブのモジュールとリンクし、 WEBアプリケーションをコンテキストルート /seam-registration
にバインドします。
これで私たちはアプリケーションにあるすべてのファイルを見ました!
フォームがサブミットされたとき、 JSF は、Seam に user
という名前の変数を解決するよう要求します。 その名前にバインドされた値が存在しないため (どの Seam コンテキストにも)、 Seam は、user
コンポーネントをインスタンス化し、 それを Seam セッションコンテキストに保管した後に、 User
エンティティ Bean インスタンスを JSF に返します。
フォームの入力値は、 User
エンティティで指定された Hibernate Validator 制約に対してデータ整合性検証が行われるようになります。 制約に違反していると JSF はそのページを再表示します。 これ以外は、 フォームの入力値を User
エンティティ Bean のプロパティにバインドします。
Next, JSF asks Seam to resolve the variable named register
. Seam finds the RegisterAction
stateless session bean in the stateless context and returns it. JSF invokes the register()
action listener method.
Seam intercepts the method call and injects the User
entity from the Seam session context, before continuing the invocation.
register()
メソッドは入力されたユーザー名が既に存在するかどうかを調べます。 存在した場合、 エラーメッセージは FacesMessages
コンポーネントでキューイングされ、 null 結果 (outcome) が返されてページが再表示されることになります。 FacesMessages
コンポーネントはメッセージ文字列に組み込まれた JSF 式を補完し、 ビュー に JSF FacesMessage
を追加します。
そのユーザー名のユーザーが存在しない場合、"/registered.xhtml"
" 結果 (outcome) により registered.xhtml
ページへのブラウザリダイレクトが発生します。 JSF がページのレンダリングに到達すると、 Seam に user
という名前の変数の解決を要求し、 Seam のセッションスコープから返される User
エンティティのプロパティ値を使用します。
データベースの検索結果をクリック可能一覧とすることは、 多くのオンラインアプリケーションにおいてたいへん重要な部分です。Seam は、EJB-QL またはHQL を使用してデータの問合せを行うことと、 その結果をJSF <h:dataTable>
を使用してクリック可能な一覧として表示することを容易にするために、 JSF 上に特別な機能を提供します。 この掲示板サンプルは、この機能を実演しています。
この掲示板サンプルは、 一つのエンティティ Bean である Message
、 一つのセッション Bean である MessageListBean
、 そして一つの JSP から構成されています。
Message
エンティティ Bean は、 タイトル、テキスト、掲示メッセージの日付と時間、 そして、メッセージが既読か否かを示すフラグを定義しています。
例 1.10. Message.java
@Entity
@Name("message")
@Scope(EVENT)
public class Message implements Serializable
{
private Long id;
private String title;
private String text;
private boolean read;
private Date datetime;
@Id @GeneratedValue
public Long getId() {
return id;
}
public void setId(Long id) {
this.id = id;
}
@NotNull @Length(max=100)
public String getTitle() {
return title;
}
public void setTitle(String title) {
this.title = title;
}
@NotNull @Lob
public String getText() {
return text;
}
public void setText(String text) {
this.text = text;
}
@NotNull
public boolean isRead() {
return read;
}
public void setRead(boolean read) {
this.read = read;
}
@NotNull
@Basic @Temporal(TemporalType.TIMESTAMP)
public Date getDatetime() {
return datetime;
}
public void setDatetime(Date datetime) {
this.datetime = datetime;
}
}
前述のサンプル同様、 一つのセッション Bean MessageManagerBean
があります。 それは、フォームにある二つのボタンに対応するアクションリスナーメソッドを定義しています。 ボタンの一つは、一覧からメッセージを選択し、 もう一つのボタンは、メッセージを削除します。 この点において、前述のサンプルと大きな違いはありません。
But MessageManagerBean
is also responsible for fetching the list of messages the first time we navigate to the message list page. There are various ways the user could navigate to the page, and not all of them are preceded by a JSF action—the user might have bookmarked the page, for example. So the job of fetching the message list takes place in a Seam factory method, instead of in an action listener method.
メッセージの一覧をサーバ要求にまたがってメモリにキャッシュしたいので、 ステートフルセッション Bean でこれを行います。
例 1.11. MessageManagerBean.java
@Stateful @Scope(SESSION) @Name("messageManager") public class MessageManagerBean implements Serializable, MessageManager { @DataModelprivate List<Message > messageList;
@DataModelS
election @Out(required=false) private Message message;
@PersistenceContext(type=EXTENDED) private EntityManager em;
@Factory("messageList") public void findMessages() { messageList = em.createQuery("select msg from Message msg order by msg.datetime desc") .getResultList(); }
public void select() { message.setRead(true); }
public void delete() { messageList.remove(message); em.remove(message); message=null; }
@Remove public void destroy() {} }
![]() |
|
![]() |
|
![]() | The |
![]() | このステートフル Bean は、EJB3 拡張永続コンテキスト を持っています。 この Bean が存在する限り、 クエリー検索された messages は、管理された状態に保持されます。 従って、 それに続くステートフル Bean へのメソッド呼び出しは、 明示的に |
![]() | 初めて JSP ページに画面遷移するとき、 |
![]() |
|
![]() |
|
![]() | すべてのステートフルセッション Bean の Seam コンポーネントは、 |
これがセッションスコープの Seam コンポーネントであることに留意してください。 ユーザーログインセッションと関連しログインセッションからのすべての要求は、 同じコンポーネントのインスタンスを共有します。 (Seam アプリケーションでは、セッションスコープのコンポーネントは控えめに使用してください。)
もちろん、すべてのセッション Bean はインタフェースを持ちます。
例 1.12. MessageManager.java
@Local
public interface MessageManager
{
public void findMessages();
public void select();
public void delete();
public void destroy();
}
ここからは、サンプルコード中のローカルインタフェースの記述を省略します。
components.xml
、persistence.xml
、web.xml
、ejb-jar.xml
、faces-config.xml
そして application.xml
は前述までのサンプルとほぼ同じなので、スキップして JSP に進みましょう。
このJSPページは JSF <h:dataTable>
コンポーネントを使用した簡単なものです。 Seam として特別なものはありません。
例 1.13. messages.jsp
<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<html>
<head>
<title
>Messages</title>
</head>
<body>
<f:view>
<h:form>
<h2
>Message List</h2>
<h:outputText value="No messages to display"
rendered="#{messageList.rowCount==0}"/>
<h:dataTable var="msg" value="#{messageList}"
rendered="#{messageList.rowCount
>0}">
<h:column>
<f:facet name="header">
<h:outputText value="Read"/>
</f:facet>
<h:selectBooleanCheckbox value="#{msg.read}" disabled="true"/>
</h:column>
<h:column>
<f:facet name="header">
<h:outputText value="Title"/>
</f:facet>
<h:commandLink value="#{msg.title}" action="#{messageManager.select}"/>
</h:column>
<h:column>
<f:facet name="header">
<h:outputText value="Date/Time"/>
</f:facet>
<h:outputText value="#{msg.datetime}">
<f:convertDateTime type="both" dateStyle="medium" timeStyle="short"/>
</h:outputText>
</h:column>
<h:column>
<h:commandButton value="Delete" action="#{messageManager.delete}"/>
</h:column>
</h:dataTable>
<h3
><h:outputText value="#{message.title}"/></h3>
<div
><h:outputText value="#{message.text}"/></div>
</h:form>
</f:view>
</body>
</html
>
最初に messages.jsp
ページに画面遷移させるとき、ページは messageList
コンテキスト変数を解決することを試みます。 このコンテキスト変数は初期化されていないため、 Seam はファクトリメソッド findMessages()
を呼び出します。 それはデータベースにクエリー発行や、 アウトジェクト (outject) された DataModel
の結果取得を行います。 この DataModel
は <h:dataTable>
をレンダリングするために必要な行データを提供します。
ユーザーが <h:commandLink>
をクリックすると、 JSF は select()
アクションリスナーを呼び出します。 Seam はこの呼び出しをインタセプトして選択された行データを messageManager
コンポーネントの message
属性にインジェクトします。 アクションリスナーが実行されて、 選択 Message
に既読マークを付けます。 呼び出しの終わりに、 Seam は、選択 Message
を message
という名前のコンテキスト変数にアウトジェクトします。 次に、 EJB コンテナはトランザクションをコミットし、 Message
に対する変更がデータベースにフラッシュされます。 最後に、 このページが再度レンダリングされてメッセージ一覧を再表示、 その下に選択メッセージが表示されます。
ユーザーが <h:commandButton>
をクリックすると、 JSF は、delete()
アクションリスナーを呼び出します。 Seam はこの呼び出しをインタセプトし、 選択された行データを messageList
コンポーネントの message
属性にインジェクトします。 アクションリスナーが起動し、 選択 Message
が一覧から削除され、 EntityManager
の remove()
が呼び出されます。 呼び出しの終わりに、 Seam は messageList
コンテキスト変数を更新し、 message
という名前のコンテキスト変数を消去します。 EJB コ ンテナはトランザクションをコミットし、 データベースから Message
を削除します。 最後に、 このページが再度レンダリングされ、 メッセージ一覧を再表示します。
jBPM はワークフローやタスク管理のための優れた機能を提供します。 どのように jBPM が Seam と統合されているかを知るために、 簡単な To-Do 一覧アプリケーションをお見せしましょう。 タスクの一覧を管理することは、jBPM の中核的機能であるため、 このサンプルには Java コードがほとんどありません。
このサンプルの中心は、jBPM のプロセス定義です。 二つの JSP と二つのちょっとした JavaBean もあります。 (データベースアクセスやトランザクション特性がないので、 セッション Bean を使用する理由はありません。) それではプロセス定義から始めましょう。
例 1.14. todo.jpdl.xml
<process-definition name="todo"> <start-state name="start"> <transition to="todo"/> </start-state> <task-node
name="todo"> <task na
me="todo" description="#{todoList.description}"> <assi
gnment actor-id="#{actor.id}"/> </task> <transition to="done"/> </task-node> <end-state
name="done"/> </process-definition >
![]() |
|
![]() |
|
![]() |
|
![]() | タスクを生成するとき、タスクはユーザーあるいはユーザーグループに割り当てる必要があります。 このサンプルでは、タスクは、現在のユーザーに割り当てられています。 現在のユーザーは |
![]() |
|
JBossIDE に提供されたプロセス定義エディタを使用してプロセス定義を見た場合、 以下のようになります。
このドキュメントは、ノードのグラフとして ビジネスプロセス を定義します。 これは現実にあり得る最小のビジネスプロセスです。実行されなければならない タスク は、一つだけです。 タスクが完了したとき ビジネスプロセスは終了します。
最初の JavaBean はログイン画面 login.jsp
を処理します。 処理は単に actor
コンポーネントを使用して jBPM actor id を初期化するだけです。 実際のアプリケーションではユーザー認証も必要です。
例 1.15. Login.java
@Name("login")
public class Login {
@In
private Actor actor;
private String user;
public String getUser() {
return user;
}
public void setUser(String user) {
this.user = user;
}
public String login()
{
actor.setId(user);
return "/todo.jsp";
}
}
ここでは、組み込み Actor
コンポーネントをインジェクトするために、 @In
を使用しているのがわかります。
次の JSP 自体は重要ではありません。
例 1.16. login.jsp
<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h"%>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%>
<html>
<head>
<title
>Login</title>
</head>
<body>
<h1
>Login</h1>
<f:view>
<h:form>
<div>
<h:inputText value="#{login.user}"/>
<h:commandButton value="Login" action="#{login.login}"/>
</div>
</h:form>
</f:view>
</body>
</html
>
二つめの JavaBean は、ビジネスプロセスインスタンスの開始とタスクの終了を担当します。
例 1.17. TodoList.java
@Name("todoList") public class TodoList { private String description; public String getDescription() { return description; } public void setDescription(String description) { this.description = description; } @CreateProc
ess(definition="todo") public void createTodo() {} @StartTask
@EndTask public void done() {} }
![]() | The description property accepts user input form the JSP page, and exposes it to the process definition, allowing the task description to be set. |
![]() | Seam |
![]() | Seam |
より現実的なサンプルでは、 @StartTask
と @EndTask
は同じメソッドの上には登場しません。 なぜなら、通常、タスクを完了するために、アプリケーションを使用して行われる仕事があるからです。
最後に、このアプリケーションのポイントは todo.jsp
にあります。
例 1.18. todo.jsp
<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<%@ taglib uri="http://jboss.com/products/seam/taglib" prefix="s" %>
<html>
<head>
<title
>Todo List</title>
</head>
<body>
<h1
>Todo List</h1>
<f:view>
<h:form id="list">
<div>
<h:outputText value="There are no todo items."
rendered="#{empty taskInstanceList}"/>
<h:dataTable value="#{taskInstanceList}" var="task"
rendered="#{not empty taskInstanceList}">
<h:column>
<f:facet name="header">
<h:outputText value="Description"/>
</f:facet>
<h:inputText value="#{task.description}"/>
</h:column>
<h:column>
<f:facet name="header">
<h:outputText value="Created"/>
</f:facet>
<h:outputText value="#{task.taskMgmtInstance.processInstance.start}">
<f:convertDateTime type="date"/>
</h:outputText>
</h:column>
<h:column>
<f:facet name="header">
<h:outputText value="Priority"/>
</f:facet>
<h:inputText value="#{task.priority}" style="width: 30"/>
</h:column>
<h:column>
<f:facet name="header">
<h:outputText value="Due Date"/>
</f:facet>
<h:inputText value="#{task.dueDate}" style="width: 100">
<f:convertDateTime type="date" dateStyle="short"/>
</h:inputText>
</h:column>
<h:column>
<s:button value="Done" action="#{todoList.done}" taskInstance="#{task}"/>
</h:column>
</h:dataTable>
</div>
<div>
<h:messages/>
</div>
<div>
<h:commandButton value="Update Items" action="update"/>
</div>
</h:form>
<h:form id="new">
<div>
<h:inputText value="#{todoList.description}"/>
<h:commandButton value="Create New Item" action="#{todoList.createTodo}"/>
</div>
</h:form>
</f:view>
</body>
</html
>
一つづつ見ていきましょう。
ページはタスク一覧をレンダリングしています。 これは、taskInstanceList
と呼ばれる Seam 組み込みコンポーネントから取得します。 この一覧はJSFフォームの中に定義されています。
例 1.19. todo.jsp
<h:form id="list">
<div>
<h:outputText value="There are no todo items." rendered="#{empty taskInstanceList}"/>
<h:dataTable value="#{taskInstanceList}" var="task"
rendered="#{not empty taskInstanceList}">
...
</h:dataTable>
</div>
</h:form
>
一覧の各要素は jBPM クラス TaskInstance
のインスタンスです。 以下のコードは単に、一覧中の各タスクの興味深いプロパティを表示しています。 記述内容 (Description) 、 優先順 (Priority) や、 納期の値 (Due Date) については、 ユーザーがこれらの値を更新できるよう入力コントロールを使用します。
<h:column>
<f:facet name="header">
<h:outputText value="Description"/>
</f:facet>
<h:inputText value="#{task.description}"/>
</h:column>
<h:column>
<f:facet name="header">
<h:outputText value="Created"/>
</f:facet>
<h:outputText value="#{task.taskMgmtInstance.processInstance.start}">
<f:convertDateTime type="date"/>
</h:outputText>
</h:column>
<h:column>
<f:facet name="header">
<h:outputText value="Priority"/>
</f:facet>
<h:inputText value="#{task.priority}" style="width: 30"/>
</h:column>
<h:column>
<f:facet name="header">
<h:outputText value="Due Date"/>
</f:facet>
<h:inputText value="#{task.dueDate}" style="width: 100">
<f:convertDateTime type="date" dateStyle="short"/>
</h:inputText>
</h:column
>
このボタンは、 @StartTask @EndTask
アノテーション付きのアクションメソッドが呼び出されることにより終了します。 それは、task id を要求パラメータとして Seam に渡します。
<h:column>
<s:button value="Done" action="#{todoList.done}" taskInstance="#{task}"/>
</h:column
>
これは seam-ui.jar
パッケージから Seam <s:button>
JSF コントロールを使用していることに留意してください。 このボタンはタスクのプロパティを更新するために使われます。 フォームがサブミットされるとき、Seam と jBPM はタスク永続に変化も起こします。 アクションリスナーメソッドには何の必要もありません。
<h:commandButton value="Update Items" action="update"/>
ページの 二つ目のフォームは新しいアイテムを作成するために使用されます。 @CreateProcess
アノテーション付きアクションメソッドから呼び出されることにより行われます。
<h:form id="new">
<div>
<h:inputText value="#{todoList.description}"/>
<h:commandButton value="Create New Item" action="#{todoList.createTodo}"/>
</div>
</h:form
>
ログイン後、todo.jsp は現在のユーザーのための未解決の To-Do 項目を表示するために taskInstanceList
を使用します。最初は何もありません。新しいエントリを登録するフォームが表示されます。ユーザーが todo 項目をタイプし、"Create New Item" ボタンを押下するとき、#{todoList.createTodo}
は呼ばれます。これは todo.jpdl.xml
で定義したプロセスを開始します。
プロセスインスタンスが生成されると、start 状態が開始されすぐに todo
状態に遷移します。そこで新しいタスクが生成されます。 タスク記述はユーザーの入力にしたがって設定されます。それは #{todoList.description}
に保存されます。 そして、タスクは現在のユーザーに割り当てられます。それは Seam の actor コンポーネントに保管されます。 このサンプルにおいて、プロセスは追加のプロセス状態を持っていないことに留意してください。 このサンプルにおけるすべての状態はタスク定義に保管されています。 プロセスとタスク情報は要求の最後でデータベースに保管されます。
todo.jsp
が再表示されるとき、taskInstanceList
はちょうど作成されたタスクを見つけます。 タスクは h:dataTable
に表示されます。 タスクの内部状態は #{task.description}
、 #{task.priority}
、 #{task.dueDate}
などのカラムに表示されます。 これらのフィールドはすべて編集やデータベースに保管可能です。
各To-Do項目は "Done" ボタンを持っていて、それは #{todoList.done}
を呼び出します。 todoList
コンポーネントは、各 s:button が taskInstance="#{task}"
を指定しているために、どのタスクボタンがテーブルの特定行のためのタスクを参照するかを知っています。 @StartTast
と @EndTask
アノテーションは タスクをアクティブにさせるものと、すぐにタスクを完了させるものです。 プロセス定義にしたがってオリジナルのプロセスが done
状態に遷移します。 そこでそれは終了します。 タスクとプロセスの状態はともにデータベースにアップデートされます。
todo.jsp
が再表示されるとき、いま完了したタスクはもう taskInstanceList
には表示されません。 なぜならコンポーネントはユーザーにとってアクティブなタスクだけを表示するからです。
比較的自由な (アドホック) 画面遷移をさせる Seam アプリケーションの場合、 JSF/Seam ナビゲーション規則がページフローを定義するのに最適な方法となります。 画面遷移に制約が多いスタイルのアプリケーションの場合、 特によりステートフルなユーザーインタフェースの場合、 ナビゲーション規則ではシステムの流れを本当に理解するのは困難になります。 フローを理解するには、 ビューページ、 アクション、 ナビゲーション規則からフローに関する情報をかき集める必要があります。
Seam は、jPDL プロセス定義を使うことでページフロー定義を可能にします。 この簡単な数字当てゲームサンプルからどのようにこれが実現されているかがわかります。
このサンプルは 一つのJavaBean、三つの JSP ページ、それと jPDL プロセスフロー定義で実装されています。 ページフローから始めましょう。
例 1.20. pageflow.jpdl.xml
<pageflow-definition xmlns="http://jboss.com/products/seam/pageflow" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://jboss.com/products/seam/pageflow http://jboss.com/products/seam/pageflow-2.1.xsd" name="numberGuess"> <start-pagename="displayGuess" view-id="/numberGuess.jspx"> <redirect/> <transit
ion name="guess" to="evaluateGuess"> <acti
on expression="#{numberGuess.guess}"/> </transition> <transition name="giveup" to="giveup"/> <transition name="cheat" to="cheat"/> </start-page>
<decision name="evaluateGuess" expression="#{numberGuess.correctGuess}"> <transition name="true" to="win"/> <transition name="false" to="evaluateRemainingGuesses"/> </decision> <decision name="evaluateRemainingGuesses" expression="#{numberGuess.lastGuess}"> <transition name="true" to="lose"/> <transition name="false" to="displayGuess"/> </decision> <page name="giveup" view-id="/giveup.jspx"> <redirect/> <transition name="yes" to="lose"/> <transition name="no" to="displayGuess"/> </page> <process-state name="cheat"> <sub-process name="cheat"/> <transition to="displayGuess"/> </process-state> <page name="win" view-id="/win.jspx"> <redirect/> <end-conversation/> </page> <page name="lose" view-id="/lose.jspx"> <redirect/> <end-conversation/> </page> </pageflow-definition >
![]() |
|
![]() |
|
![]() | transition の |
![]() |
|
以下は JBoss Developer Studio ページフローエディタでどのように表示するかを示しています。
ページフローを見終わりました。 アプリケーションの残りの部分を理解することはもう簡単です。
これがアプリケーションの中心のページ numberGuess.jspx
です。
例 1.21. numberGuess.jspx
<<?xml version="1.0"?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:s="http://jboss.com/products/seam/taglib"
xmlns="http://www.w3.org/1999/xhtml"
version="2.0">
<jsp:output doctype-root-element="html"
doctype-public="-//W3C//DTD XHTML 1.0 Transitional//EN"
doctype-system="http://www.w3c.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"/>
<jsp:directive.page contentType="text/html"/>
<html>
<head>
<title
>Guess a number...</title>
<link href="niceforms.css" rel="stylesheet" type="text/css" />
<script language="javascript" type="text/javascript" src="niceforms.js" />
</head>
<body>
<h1
>Guess a number...</h1>
<f:view>
<h:form styleClass="niceform">
<div>
<h:messages globalOnly="true"/>
<h:outputText value="Higher!"
rendered="#{numberGuess.randomNumber gt numberGuess.currentGuess}"/>
<h:outputText value="Lower!"
rendered="#{numberGuess.randomNumber lt numberGuess.currentGuess}"/>
</div>
<div>
I'm thinking of a number between
<h:outputText value="#{numberGuess.smallest}"/> and
<h:outputText value="#{numberGuess.biggest}"/>. You have
<h:outputText value="#{numberGuess.remainingGuesses}"/> guesses.
</div>
<div>
Your guess:
<h:inputText value="#{numberGuess.currentGuess}" id="inputGuess"
required="true" size="3"
rendered="#{(numberGuess.biggest-numberGuess.smallest) gt 20}">
<f:validateLongRange maximum="#{numberGuess.biggest}"
minimum="#{numberGuess.smallest}"/>
</h:inputText>
<h:selectOneMenu value="#{numberGuess.currentGuess}"
id="selectGuessMenu" required="true"
rendered="#{(numberGuess.biggest-numberGuess.smallest) le 20 and
(numberGuess.biggest-numberGuess.smallest) gt 4}">
<s:selectItems value="#{numberGuess.possibilities}" var="i" label="#{i}"/>
</h:selectOneMenu>
<h:selectOneRadio value="#{numberGuess.currentGuess}" id="selectGuessRadio"
required="true"
rendered="#{(numberGuess.biggest-numberGuess.smallest) le 4}">
<s:selectItems value="#{numberGuess.possibilities}" var="i" label="#{i}"/>
</h:selectOneRadio>
<h:commandButton value="Guess" action="guess"/>
<s:button value="Cheat" view="/confirm.jspx"/>
<s:button value="Give up" action="giveup"/>
</div>
<div>
<h:message for="inputGuess" style="color: red"/>
</div>
</h:form>
</f:view>
</body>
</html>
</jsp:root
>
アクションを直接呼び出す代わりに、 どのようにコマンドボタンはguess
transitionを指定しているかに着目してください。
win.jspx
ページはごく普通のものです。
例 1.22. win.jspx
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:h="http://java.sun.com/jsf/html" xmlns:f="http://java.sun.com/jsf/core" xmlns="http://www.w3.org/1999/xhtml" version="2.0"> <jsp:output doctype-root-element="html" doctype-public="-//W3C//DTD XHTML 1.0 Transitional//EN" doctype-system="http://www.w3c.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"/> <jsp:directive.page contentType="text/html"/> <html> <head> <title >You won!</title> <link href="niceforms.css" rel="stylesheet" type="text/css" /> </head> <body> <h1 >You won!</h1> <f:view> Yes, the answer was <h:outputText value="#{numberGuess.currentGuess}" />. It took you <h:outputText value="#{numberGuess.guessCount}" /> guesses. <h:outputText value="But you cheated, so it doesn't count!" rendered="#{numberGuess.cheat}"/> Would you like to <a href="numberGuess.seam" >play again</a >? </f:view> </body> </html> </jsp:root>
lose.jspx
はほぼ同じです。 説明は省略します。
最後に、実際のアプリケーションコードを見ましょう。
例 1.23. NumberGuess.java
@Name("numberGuess")
@Scope(ScopeType.CONVERSATION)
public class NumberGuess implements Serializable {
private int randomNumber;
private Integer currentGuess;
private int biggest;
private int smallest;
private int guessCount;
private int maxGuesses;
private boolean cheated;
@Create
public void begin()
{
randomNumber = new Random().nextInt(100);
guessCount = 0;
biggest = 100;
smallest = 1;
}
public void setCurrentGuess(Integer guess)
{
this.currentGuess = guess;
}
public Integer getCurrentGuess()
{
return currentGuess;
}
public void guess()
{
if (currentGuess
>randomNumber)
{
biggest = currentGuess - 1;
}
if (currentGuess<randomNumber)
{
smallest = currentGuess + 1;
}
guessCount ++;
}
public boolean isCorrectGuess()
{
return currentGuess==randomNumber;
}
public int getBiggest()
{
return biggest;
}
public int getSmallest()
{
return smallest;
}
public int getGuessCount()
{
return guessCount;
}
public boolean isLastGuess()
{
return guessCount==maxGuesses;
}
public int getRemainingGuesses() {
return maxGuesses-guessCount;
}
public void setMaxGuesses(int maxGuesses) {
this.maxGuesses = maxGuesses;
}
public int getMaxGuesses() {
return maxGuesses;
}
public int getRandomNumber() {
return randomNumber;
}
public void cheated()
{
cheated = true;
}
public boolean isCheat() {
return cheated;
}
public List<Integer
> getPossibilities()
{
List<Integer
> result = new ArrayList<Integer
>();
for(int i=smallest; i<=biggest; i++) result.add(i);
return result;
}
}
![]() | 最初に、JSP ページが |
pages.xml
ファイルは Seam 対話 (conversation) を開始し ( 詳細は後述 )、対話のページフローを使用するためのページフロー定義を規定します。
例 1.24. pages.xml
<?xml version="1.0" encoding="UTF-8"?>
<pages xmlns="http://jboss.com/products/seam/pages"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://jboss.com/products/seam/pages http://jboss.com/products/seam/pages-2.1.xsd">
<page view-id="/numberGuess.jspx">
<begin-conversation join="true" pageflow="numberGuess"/>
</page>
</pages
>
見てわかるように、この Seam コンポーネントは純粋なビジネスロジックです! ユーザーインタラクションのフローについて理解する必要はまったくありません。 これによりコンポーネント再利用性を本当に向上させます。
アプリケーションの基本的なフローを見てみましょう。 ゲームは numberGuess.jspx
から始まります。 始めてページが表示されたとき、pages.xml
設定は対話を開始させ numberGuess
ページフローを対話と関連付けます。 ページフローは 待機状態であるstart-page
から開始されるので numberGuess.xhtml
が表示されます。
ビューは numberGuess
コンポーネントを参照します。 その結果新しいインスタンスが生成され対話に保管されます。 @Create
メソッドが呼ばれゲームの状態が初期化されます。 ビューはユーザーが #{numberGuess.currentGuess}
を編集可能な h:form
を表示します。
"Guess" ボタンは guess
アクションを呼び起こします。 Seam はアクションを処理するためにページフローに従います。それはページフローが evaluateGuess
状態に遷移することを命じます。 最初の呼び出し #{numberGuess.guess}
は guess count と numberGuess
コンポーネント中の highest/lowest suggestions を更新します。
evaluateGuess
状態は #{numberGuess.correctGuess}
の値をチェックし win
または evaluatingRemainingGuesses
状態に遷移させます。 数字が間違っていたとすると、その場合ページフローは evaluatingRemainingGuesses
に遷移します。 それは decision 状態であり、 ユーザーがまだ数字当てをするか否かを決定するために #{numberGuess.lastGuess}
をテストします。 まだ数字あてをするならば ( lastGuess
が false
)、最初の displayGuess
状態に遷移させます。 最後に、page 状態に達し、関連するページ /numberGuess.jspx
が表示されます。ページは redirect 要素を持っているので、Seam はユーザーのブラウザにリダイレクトを送信しプロセスを再始動させます。
以降の要求により win
または lose
に遷移する状態以外これ以上状態については説明しません。つまりユーザーが /win.jspx
または /lose.jspx
を取得することについてです。 両方の状態は Seam が対話を終了し、ユーザーに最終ページをリダイレクトする前に、ゲームの状態やページフローの状態を破棄することを規定しています。
The numberguess example also contains Giveup and Cheat buttons. You should be able to trace the pageflow state for both actions relatively easily. Pay particular attention to the cheat
transtition, which loads a sub-process to handle that flow. Although it's overkill for this application, it does demonstrate how complex pageflows can be broken down into smaller parts to make them easier to understand.
この予約アプリケーションは以下の特徴を持つ本格的なホテルの部屋予約システムです。
ユーザー登録
ログイン
ログアウト
パスワード設定
ホテル検索
ホテル選択
部屋予約
予約確認
現状の予約一覧
この予約アプリケーションは JSF、EJB 3.0、Seam とともにビューとして Facelet を使用しています。 JSF、Facelets、Seam、JavaBeans そして、Hibernate3 のアプリケーションの移植版もあります
このアプリケーションをある程度の期間、 いじってわかることの一つはそれがとても堅牢であることです。 戻るボタンを操作してもブラウザの更新をしても複数のウィンドを開いても無意味なデータを好きなだけ入力してもアプリケーションをクラッシュさせることがとても困難であることがわかります。 これを達成するためにテストやバグ取りに何週間も掛かったと思われるかもしれませんが、 実際にはそんなことはありません。 Seam は、堅牢な WEB アプリケーションを簡単に構築できるように設計されています。 そして、これまでコーディングそのものによって得られていた堅牢性は Seam を使用することで自然かつ自動的に得られます。
サンプルアプリケーションのコードを見れば、 どのようにアプリケーションが動作しているか習得できます。 そして、この堅牢性の達成するために、 どのように宣言的状態管理や統合されたデータ妥当性検証が使用されているかを見ることができます。
プロジェクトの構成はこれまでのものと同じです。 このアプリケーションをインストールするには、項1.1. 「Seam サンプルを使用する」 を参照してください。 うまくアプリケーションが起動したならば、 ブラウザから http://localhost:8080/seam-booking/
を指定してアクセス可能です。
このアプリケーションは以下の機能を実装するビジネスロジックのために 6 つのセッション Bean を使用しています。
AuthenticatorAction
はログイン認証ロジックを提供します。
BookingListAction
は、その時のログインユーザーのために現状の予約を取得します。
ChangePasswordAction
は、その時のログインユーザーのパスワードを変更します。
HotelBookingAction
は、アプリケーションの中核的機能を実装します。 この機能は 対話 として実装されるため、 このアプリケーションの中でもっとも興味を引くクラスです。
HotelSearchingAction
はホテル検索を実装しています。
RegisterAction
は、新しいシステムユーザーを登録します。
三つのエンティティ Bean はアプリケーション永続ドメインモデルを実装しています。
Hotel
はホテルを表現するエンティティ Bean です。
Booking
は、現状の予約を表すエンティティ Bean です。
User
は、ホテル予約ができるユーザーを表すエンティティ Bean です。
気が向いたならばソースコードを読まれることをお勧めします。 このチュートリアルでは、特定の機能つまりホテル検索、選択、予約と確認を集中して説明します。 ユーザーの視点から見ると、 ホテルの選択から予約確認までのすべては、一つの連続した仕事の単位、 つまり対話です。 しかし、検索は対話の一部ではありません。 ユーザーは異なるブラウザタブで同じ検索結果のページから複数のホテルを選択可能です。
ほとんどの WEB アプリケーションのアーキテクチャは対話を扱うためのファーストクラスの構造を持っていません。 これは対話の状態を管理するために重大な問題となります。通常、Java WEB アプリケーションは二つの技術を組み合わせて使用します。 ある状態は URL に変換可能です。 不可能なものはすべての要求の後に HttpSession
に投げられるかあるいはデータベースにフラッシュされます。そしてすべての新しい要求の最初にデータベースから再構築されます。
データベースは最もスケーラビリティに乏しい層なので、 許容不能なほどスケーラビリティに乏しい結果となることがよくあります。 要求ごとデータベースを行き来する転送量が増加すると、追加される待ち時間も問題となります。この冗長な転送量を減少させるために、Java アプリケーションでは要求間でよくアクセスされるデータを保管するデータキャッシュ (2 次レベル) をしばしば導入します。 このキャッシュは必ずしも効率的ではありません。 なぜならデータが無効かどうかの判断をユーザーがデータの操作を終了したかどうかをもとにして行うのではなく LRU ポリシーをベースとして行うためです。 さらに、 キャッシュは多くの並列トランザクション間で共有されるので、 キャッシュされた状態とデータベース間の一貫性維持に関する多くの問題をも取り入れてしまうことになるためです。
さて HttpSession
に保管された状態を考察してみましょう。 HttpSession はセッションデータにとってとても便利な場所です。 つまりユーザーがアプリケーションとして持つすべての要求に共通なデータにとって。 しかし、一連の個別の要求に関するデータを保管する場所としては適しません。 戻るボタンや複数のウィンドウを操作するとき、対話的なセッションの使用はすぐに破たんしてしまいます。 それに加えて、慎重なプログラミングがなければ、HTTP セッションのデータはとても大きくなり、HTTP セッションをクラスタに対応させることが困難になる可能性があります。 異なる同時並行的な対話に関連するセッション状態を分離するメカニズムを開発することや、ブラウザウィンドウまたはタブを閉じることでユーザーが対話の一つを中断するときに対話状態が破棄されることを保証するフェイルセーフを組み込むことは簡単な仕事ではありません。 幸いにも Seam にはそんな心配は無用です。
Seam はファーストクラスの構造として対話コンテキスト (conversation context) を導入しています。 このコンテキストで対話状態は安全に維持することが可能で、 また明確なライフサイクルを持つことが保証されます。 さらに良いことに、 対話コンテキストはユーザーが現在作業しているデータの自然なキャッシュとなるため、 アプリケーションサーバーとデータベース間でデータを継続的に行き来させる必要がありません。
このアプリケーションでは、ステートフルセッション Bean を保管するために対話コンテキストを使用します。 Java コミュニティには、ステートフルセッション Bean はスケーラビリティ殺しだというデマが古くからあります。 初期のエンタープライズ Java では真実であったかもしれませんが、今日ではもはや真実ではありません。 今日のアプリケーションサーバーはステートフルセッション Bean の状態を複製するために極めて洗練されたメカニズムを持っています。 例えば、JBoss AS はきめの細かい複製を行い、 実際に変化した bean 属性値のみの複製を行います。 ステートフル Bean が非効率的かという伝統的技術論はすべて HttpSession
にも等しく当てはまります。 その結果パフォーマンスを改善するためにビジネス層のステートフルセッション Bean から Web セッションに移行する慣習は驚くほど誤解されていることに留意してください。間違ってステートフル Bean を使用することあるいは間違ったもののためにそれらを使うことによって、スケーラブルでないアプリケーションを書く可能性は確かにあります。 しかしそれは使うべきでないということにはなりません。もし納得できなければ、Seam ではセッション Bean の代わりに POJO を使用することも可能です。 Seam では、選択はあなた次第です。
この予約サンプルアプリケーションは、 複雑な振る舞いを実現するために、 異なるスコープを持つステートフルコンポーネントがどのように連携することが可能であるかを示しています。 予約アプリケーションのメインページは、 ユーザーにホテル検索を可能にしています。 検索結果は、Seam セッションスコープに保持されます。 ユーザーがこれらのホテルの一つに遷移するとき、 対話は、開始します。 そして、対話スコープのコンポーネントは、 選択されたホテルを取得するために、 セッションスコープのコンポーネントを呼び返します。
手書きの JavaScript を使用することなくリッチクライアントの振る舞いを実装するためにホテル予約サンプルは RichFaces Ajax の使用を実演しています。
検索機能は、セッションスコープのステートフル Bean を使用して実装されます。 それはメッセージ一覧サンプルに見られるものと同様です。
例 1.25. HotelSearchingAction.java
@Stateful@Name("hotelSearch") @Scope(ScopeType.SESSION) @Restrict("#{i
dentity.loggedIn}") public class HotelSearchingAction implements HotelSearching { @PersistenceContext private EntityManager em; private String searchString; private int pageSize = 10; private int page; @DataModel
private List<Hotel > hotels; public void find() { page = 0; queryHotels(); } public void nextPage() { page++; queryHotels(); } private void queryHotels() { hotels = em.createQuery("select h from Hotel h where lower(h.name) like #{pattern} " + "or lower(h.city) like #{pattern} " + "or lower(h.zip) like #{pattern} " + "or lower(h.address) like #{pattern}") .setMaxResults(pageSize) .setFirstResult( page * pageSize ) .getResultList(); } public boolean isNextPageAvailable() { return hotels!=null && hotels.size()==pageSize; } public int getPageSize() { return pageSize; } public void setPageSize(int pageSize) { this.pageSize = pageSize; } @Factory(value="pattern", scope=ScopeType.EVENT) public String getSearchPattern() { return searchString==null ? "%" : '%' + searchString.toLowerCase().replace('*', '%') + '%'; } public String getSearchString() { return searchString; } public void setSearchString(String searchString) { this.searchString = searchString; }
@Remove public void destroy() {} }
![]() | EJB 標準 |
![]() |
|
![]() | |
![]() | EJB 標準の |
アプリケーションの中心となるページは Facelets ページです。 ホテルを検索に関連する部分を見てみましょう。
例 1.26. main.xhtml
<div class="section"> <span class="errors"> <h:messages globalOnly="true"/> </span> <h1 >Search Hotels</h1> <h:form id="searchCriteria"> <fieldset > <h:inputText id="searchString" value="#{hotelSearch.searchString}"style="width: 165px;"> <a:support event="onkeyup" actionListener="#{hotelSearch.find}" reRender="searchResults" /> </h:inputText>   <a:commandButton id="findHotels" value="Find Hotels" action="#{hotelSearch.find}"
reRender="searchResults"/>   <a:status> <f:facet name="start"> <h:graphicImage value="/img/spinner.gif"/> </f:facet> </a:status> <br/> <h:outputLabel for="pageSize" >Maximum results:</h:outputLabel >  <h:selectOneMenu value="#{hotelSearch.pageSize}" id="pageSize"> <f:selectItem itemLabel="5" itemValue="5"/> <f:selectItem itemLabel="10" itemValue="10"/> <f:selectItem itemLabel="20" itemValue="20"/> </h:selectOneMenu> </fieldset> </h:form>
</div> <a:outputPanel id="searchResults"> <div class="section"> <h:outputText value="No Hotels Found" rendered="#{hotels != null and hotels.rowCount==0}"/> <h:dataTable id="hotels" value="#{hotels}" var="hot" rendered="#{hotels.rowCount >0}"> <h:column> <f:facet name="header" >Name</f:facet> #{hot.name} </h:column> <h:column> <f:facet name="header" >Address</f:facet> #{hot.address} </h:column> <h:column> <f:facet name="header" >City, State</f:facet> #{
hot.city}, #{hot.state}, #{hot.country} </h:column > <h:column> <f:facet name="header" >Zip</f:facet> #{hot.zip} </h:column> <h:column> <f:facet name="header" >Action</f:facet> <s:link id="viewHotel" value="View Hotel" action="#{hotelBooking.selectHotel(hot)}"/> </h:column> </h:dataTable> <s:link value="More results" action="#{hotelSearch.nextPage}" rendered="#{hotelSearch.nextPageAvailable}"/> </div> </a:outputPanel >
![]() | RichFaces Ajax |
![]() | RichFaces Ajax |
![]() | RichFaces Ajax |
![]() | Seam どのようにナビゲーションが起こるかと思うならば、 |
このページは、タイプしたときに検索結果が動的に表示し、 ホテルの選択をさせ、 HotelBookingAction
の selectHotel()
メソッドに選択結果を渡します。 そこでは、かなり興味深いことが起こっています。
対話と関連する永続データを自然にキャッシュするために予約サンプルアプリケーションがどのように対話スコープのステートフル Bean を利用するか見てみましょう。 以下のサンプルコードは結構長いですが、対話の各種ステップを実装するスクリプト化された動作の一覧と考えると理解できます。 ストーリーを読むように徹底的に読んでください。
例 1.27. HotelBookingAction.java
@Stateful @Name("hotelBooking") @Restrict("#{identity.loggedIn}") public class HotelBookingAction implements HotelBooking { @PersistenceContext(type=EXTENDED) private EntityManager em; @In private User user; @In(required=false) @Out private Hotel hotel; @In(required=false) @Out(requir
ed=false) private Booking booking; @In private FacesMessages facesMessages; @In private Events events; @Logger private Log log; private boolean bookingValid; @Begin
public void selectHotel(Hotel selectedHotel) { hotel = em.merge(selectedHotel); } public void bookHotel() { booking = new Booking(hotel, user); Calendar calendar = Calendar.getInstance(); booking.setCheckinDate( calendar.getTime() ); calendar.add(Calendar.DAY_OF_MONTH, 1); booking.setCheckoutDate( calendar.getTime() ); } public void setBookingDetails() { Calendar calendar = Calendar.getInstance(); calendar.add(Calendar.DAY_OF_MONTH, -1); if ( booking.getCheckinDate().before( calendar.getTime() ) ) { facesMessages.addToControl("checkinDate", "Check in date must be a future date"); bookingValid=false; } else if ( !booking.getCheckinDate().before( booking.getCheckoutDate() ) ) { facesMessages.addToControl("checkoutDate", "Check out date must be later than check in date"); bookingValid=false; } else { bookingValid=true; } } public boolean isBookingValid() { return bookingValid; } @End
public void confirm() { em.persist(booking); facesMessages.add("Thank you, #{user.name}, your confimation number " + " for #{hotel.name} is #{booki g.id}"); log.info("New booking: #{booking.id} for #{user.username}"); events.raiseTransactionSuccessEvent("bookingConfirmed"); } @End public void cancel() {} @Remove
public void destroy() {}
![]() | この Bean は、EJB3 拡張永続コンテキスト を使用します。 その結果、エンティティインスタンスは、 ステートフルセッション Bean のライフサイクル全体の管理を維持します。 |
![]() | |
![]() | |
![]() | |
![]() | Seam は、対話コンテキストを破棄するときこの EJB remove メソッドは呼び出されるでしょう。 このメソッドを定義することを忘れないでください。 |
HotelBookingAction
はホテル選択、予約、予約確認を実装したすべてのアクションリスナーを持っており、 そしてこの操作に関連する状態をインスタンスに保持しています。 このコードが、 HttpSession
属性から get/set するものと比較してよりクリーンで簡単なコードであることに同意してもらえると思います。
さらに良いことに、ユーザーは、ログインセッション毎に複数の分離された対話を持つことが可能です。 試してみてください。 ログインして、検索して、複数のブラウザタブに異なるホテルのページを表示させてください。 同時に二つの異なるホテル予約を作成することが可能です。 対話を長時間放置した場合、 Seam は最終的に対話をタイムアウトし状態を破棄します。 対話が終了した後に、その対話ページに戻るボタンを押し処理実行を試みた場合、 Seam は対話が既に終了したことを検出し検索ページにリダイレクトします。
WAR は seam-debug.jar
も含みます。 Seam デバッグページは WEB-INF/lib
に Facelets と合わせてこの jar がデプロイされ、init
コンポーネントの debug プロパティが以下のように設定された場合に有効になります。
<core:init jndi-pattern="@jndiPattern@" debug="true"/>
このページで現在ログインしているセッションに関連するすべての Seam コンテキスト中の Seam コンポーネントを見たり検査することができます。 使い方は単にブラウザから http://localhost:8080/seam-booking/debug.seam
を指定するだけです。
長期対話はマルチウインドウ操作やも戻るボタンに直面してもアプリケーションの状態の一貫性を維持することを容易にします。 残念なことに、長期対話の開始や終了は通常十分ではありません。 アプリケーション要件に応じて、ユーザーの期待するもとのアプリケーションの状態の現実の間の矛盾は結果としてまだ生じます。
ネストされたホテル予約アプリケーションは部屋の選択を関連づけるためホテル予約アプリケーションの機能を拡張しています。 それぞれのホテルはユーザーが選択するために宿泊可能な部屋を説明付きで持っています。 これはホテルの予約の流れにおいて部屋選択ページの機能追加を必要とします。
ユーザーはその時予約に含まれるべき宿泊可能な部屋のオプションを持っています。 これまで見たホテルの予約アプリケーションと同様に、これは状態の一貫性の問題を引き起こす可能性があります。 HTTPSession
に状態を保管するように、対話変数が変更すると同じ対話コンテキストの中で動作しているすべてのウィンドウに影響します。
これを実演するために、ユーザーが一つの新しいウィンドウでの中でまったく同じの選択画面を表示させたとします。 そしてユーザーは Wonderful Room を選択して確認画面に進みます。 上流の生活を過ごすのにどれだけかかるかを見るために、ユーザーはもともとの画面を戻して、予約のために Fantastic Suite を選択し、再び確認に進みます。 総費用を見直した後に、ユーザーは実用性を重視して確認のために Wonderful Room を表示するウィンドウに戻ることを決めました。
このシナリオでは、単純にすべての状態を対話に保管するならば、同じ対話なかにある複数ウィンドウの操作を保護できません。 ネストされた対話は同じ対話中でコンテキストが変更するときでさえユーザーの正しい振る舞いを達成可能にしています。
さあ、ネストされたホテル予約サンプルがネストされた対話を使用することでどのようにホテル予約アプリケーション機能拡張させているか見てみましょう。 繰り返しになりますが、物語のようにクラスを徹底的に読むことができます。
例 1.28. RoomPreferenceAction.java
@Stateful @Name("roomPreference") @Restrict("#{identity.loggedIn}") public class RoomPreferenceAction implements RoomPreference { @Logger private Log log; @In private Hotel hotel; @In private Booking booking; @DataModel(value="availableRooms") private List<Room > availableRooms; @DataModelSelection(value="availableRooms") private Room roomSelection; @In(required=false, value="roomSelection") @Out(required=false, value="roomSelection") private Room room; @Factory("availableRooms") public void loadAvailableRooms() { availableRooms = hotel.getAvailableRooms(booking.getCheckinDate(), booking.getCheckoutDate()); log.info("Retrieved #0 available rooms", availableRooms.size()); } public BigDecimal getExpectedPrice() { log.info("Retrieving price for room #0", roomSelection.getName()); return booking.getTotal(roomSelection); }
@Begin(nested=true) public String selectPreference() { log.info("Room selected");
this.room = this.roomSelection; return "payment"; } public String requestConfirmation() { // all validations are performed through the s:validateAll, so checks are already // performed log.info("Request confirmation from user"); return "confirm"; } @End(before
Redirect=true) public String cancel() { log.info("ending conversation"); return "cancel"; } @Destroy @Remove public void destroy() {} }
![]() | The |
![]() | |
![]() |
|
![]() | |
ネストされた対話にあるとき対話スタックにプッシュされます。 nestedbooking
サンプルでは、対話スタックは外側の長期対話 (booking) とそれぞれのネストされた対話 (room selections) から構成されます。
例 1.29. rooms.xhtml
<div class="section"> <h1 >Room Preference</h1> </div> <div class="section"> <h:form id="room_selections_form"> <div class="section"> <h:outputText styleClass="output" value="No rooms available for the dates selected: " rendered="#{availableRooms != null and availableRooms.rowCount == 0}"/> <h:outputText styleClass="output" value="Rooms available for the dates selected: " rendered="#{availableRooms != null and availableRooms.rowCount > 0}"/> <h:outputText styleClass="output" value="#{booking.checkinDate}"/> - <h:outputText styleClass="output" value="#{booking.checkoutDate}"/><br/><br/> <h:dataTable value="#{availableRooms}" var="room" rendered="#{availableRooms.rowCount > 0}"> <h:column> <f:facet name="header" >Name</f:facet> #{room.name} </h:column> <h:column> <f:facet name="header" >Description</f:facet> #{room.description} </h:column> <h:column>
<f:facet name="header" >Per Night</f:facet> <h:outputText value="#{room.price}"> <f:convertNumber type="currency" currencySymbol="$"/> </h:outputText> </h:column> <h:column> <f:facet name="header" >Action</f:facet>
<h:commandLink id="selectRoomPreference" action="#{roomPreference.selectPreference}" >Select</h:commandLink> </h:column> </h:dataTable> </div> <div class="entry"> <div class="label" > </div> <div class="input"> <s:button id="cancel" value="Revise Dates" view="/book.xhtml"/> </div> </div > </h:form> </div>
![]() | EL から要求されるとき、 |
![]() |
|
![]() | 日付の変更は単純に |
今や対話のネスティングの方法がわかったので、部屋が選ばれたらどのように予約を確認することができるかを見てみましょう。 これは HotelBookingAction
.の振る舞いを単に拡張することによって達成可能です。
例 1.30. HotelBookingAction.java
@Stateful @Name("hotelBooking") @Restrict("#{identity.loggedIn}") public class HotelBookingAction implements HotelBooking { @PersistenceContext(type=EXTENDED) private EntityManager em; @In private User user; @In(required=false) @Out private Hotel hotel; @In(required=false) @Out(required=false) private Booking booking; @In(required=false) private Room roomSelection; @In private FacesMessages facesMessages; @In private Events events; @Logger private Log log; @Begin public void selectHotel(Hotel selectedHotel) { log.info("Selected hotel #0", selectedHotel.getName()); hotel = em.merge(selectedHotel); } public String setBookingDates() { // the result will indicate whether or not to begin the nested conversation // as well as the navigation. if a null result is returned, the nested // conversation will not begin, and the user will be returned to the current // page to fix validation issues String result = null; Calendar calendar = Calendar.getInstance(); calendar.add(Calendar.DAY_OF_MONTH, -1); // validate what we have received from the user so far if ( booking.getCheckinDate().before( calendar.getTime() ) ) { facesMessages.addToControl("checkinDate", "Check in date must be a future date"); } else if ( !booking.getCheckinDate().before( booking.getCheckoutDate() ) ) { facesMessages.addToControl("checkoutDate", "Check out date must be later than check in date"); } else { result = "rooms"; } return result; } public void bookHotel() { booking = new Booking(hotel, user); Calendar calendar = Calendar.getInstance(); booking.setCheckinDate( calendar.getTime() ); calendar.add(Calendar.DAY_OF_MONTH, 1); booking.setCheckoutDate( calendar.getTime() ); } @End(root=true) public voidconfirm() { // on confirmation we set the room preference in the booking. the room preference // will be injected based on the nested conversation we are in. booking.setRoomPreference(roomSelection);
em.persist(booking); facesMessages.add("Thank you, #{user.name}, your confimation number for #{hotel.name} is #{booking.id}"); log.info("New booking: #{booking.id} for #{user.username}"); events.raiseTransactionSuccessEvent("bookingConfirmed"); } @End(root=t
rue, beforeRedirect=true) public void cancel() {} @Destroy @Remove public void destroy() {} }
![]() | Annotating an action with |
![]() |
|
![]() | |
気軽にアプリケーションをデプロイし、たくさんのウィンドウやタブを開きさまざまな好みの部屋によるさまざまなホテルの組み合わせを試してみて下さい。 予約確認はネストされた対話モデルのおかげで正しいホテルと好みの部屋をもたらします。
DVD ストアのデモアプリケーションは、 タスク管理とページフローのための jBPM の実践的な使用法を見せてくれます。
ユーザー画面は、検索やショッピングカート機能の実装のために jPDL ページフローを利用しています。
この管理画面は、オーダの承認やショッピングサイクルを管理するために jBPM を利用します。 ビジネスプロセスは、異なるプロセス定義を選択することにより動的に変更されるかもしれません。
Seam DVD ストアデモは他のでもアプリケーション同様に dvdstore
ディレクトリから起動できます。
Seam はサーバサイドで状態保持するアプリケーションの実装をとても容易にします。 しかし、サーバサイドの状態管理はいつも適切というわけではありません。 (特に、コンテンツ (content) を提供する機能において ) この種の問題のために、ユーザーにページをブックマークさせ、 そして、比較的ステートレスなサーバとする必要がしばしばあります、 その結果、ブックマークを通していつでもどんなページにもアクセス可能になります。 この Blog サンプルは Seam を使用した RESTful アプリケーションの実装方法を見せてくれます。 検索結果ページを含むすべてのアプリケーションのページはブックマークが可能です。
この Blog サンプルは、"引っぱり (PULL) " - スタイル MVC の使用を実演しています。 ここで、ビューのためのデータ取得とデータ準備のアクションメソッドリスナーを使用する代わりに、 ビューは、レンダリングしているコンポーネントからデータを引き出します (PULL) 。
index.xhtml
facelets ページの一部は最新のブログエントリの一覧を表示しています。
例 1.31.
<h:dataTable value="#{blog.recentBlogEntries}" var="blogEntry" rows="3">
<h:column>
<div class="blogEntry">
<h3
>#{blogEntry.title}</h3>
<div>
<s:formattedText value="#{blogEntry.excerpt==null ? blogEntry.body : blogEntry.excerpt}"/>
</div>
<p>
<s:link view="/entry.xhtml" rendered="#{blogEntry.excerpt!=null}" propagation="none"
value="Read more...">
<f:param name="blogEntryId" value="#{blogEntry.id}"/>
</s:link>
</p>
<p>
[Posted on 
<h:outputText value="#{blogEntry.date}">
<f:convertDateTime timeZone="#{blog.timeZone}" locale="#{blog.locale}" type="both"/>
</h:outputText
>]
 
<s:link view="/entry.xhtml" propagation="none" value="[Link]">
<f:param name="blogEntryId" value="#{blogEntry.id}"/>
</s:link>
</p>
</div>
</h:column>
</h:dataTable
>
If we navigate to this page from a bookmark, how does the #{blog.recentBlogEntries}
data used by the <h:dataTable>
actually get initialized? The Blog
is retrieved lazily—"pulled"—when needed, by a Seam component named blog
. This is the opposite flow of control to what is used in traditional action-based web frameworks like Struts.
例 1.32.
@Name("blog") @Scope(ScopeType.STATELESS) @AutoCreate public class BlogService { @In EntityManager entityManager; @Unwrap
public Blog getBlog() { return (Blog) entityManager.createQuery("select distinct b from Blog b left join fetch b.blogEntries") .setHint("org.hibernate.cacheable", true) .getSingleResult(); } }
![]() | このコンポーネントは Seam 管理永続コンテキスト (seam-managed persistence context) を使用しています。 これまで見てきた他のサンプルとは異なり、この永続コンテキストは、EJB3 コンテナの代わりに Seam により管理されます。 永続コンテキストは Web 要求全体におよび、ビューにおいてフェッチしていない関連にアクセスするときに発生する例外を回避することが可能です。 |
![]() | The |
これは、これまでのところ良いですが、 検索結果ページのようなフォームサブミットの結果のブックマークではどうでしょうか?
この Blog サンプルは、 各ページの右上にユーザーの Blog 記事の検索を可能にする小さなフォームを持ちます。 これは、facelet テンプレート、template.xhtml
に含まれる menu.xhtml
ファイルに定義されます。
例 1.33.
<div id="search">
<h:form>
<h:inputText value="#{searchAction.searchPattern}"/>
<h:commandButton value="Search" action="/search.xhtml"/>
</h:form>
</div
>
ブックマーク可能検索結果ページの実装のために、 検索フォームのサブミットを処理した後に、 ブラウザリダイレクトを実行する必要があります。 アクション結果 (outcome) として JSF ビュー ID を使用しているので、 Seam は、フォームがサブミットされたとき、自動的に ビュー ID にリダイレクトします。 別の方法として、以下のようなナビゲーションルールを定義することも可能です。
<navigation-rule>
<navigation-case>
<from-outcome
>searchResults</from-outcome>
<to-view-id
>/search.xhtml</to-view-id>
<redirect/>
</navigation-case>
</navigation-rule
>
フォームは、以下と似たようなものになるでしょう。
<div id="search">
<h:form>
<h:inputText value="#{searchAction.searchPattern}"/>
<h:commandButton value="Search" action="searchResults"/>
</h:form>
</div
>
But when we redirect, we need to include the values submitted with the form in the URL get a bookmarkable URL like http://localhost:8080/seam-blog/search/
. JSF does not provide an easy way to do this, but Seam does. We use two Seam features to accomplish this: page parameters and URL rewriting. Both are defined in WEB-INF/pages.xml
:
例 1.34.
<pages>
<page view-id="/search.xhtml">
<rewrite pattern="/search/{searchPattern}"/>
<rewrite pattern="/search"/>
<param name="searchPattern" value="#{searchService.searchPattern}"/>
</page>
...
</pages
>
検索ページへの要求があるときや検索ページへのリンクが生成されるときはいつでも、ページパラメータは Seam に searchPattern
という名前の要求パラメータを #{searchService.searchPattern}
の値にリンクすることを指示します。 Seam は URL とアプリケーションの状態のリンクについて維持することに責任を持ちます。 私たちや開発者はそれを心配する必要はありません。
Without URL rewriting, the URL for a search on the term book
would be http://localhost:8080/seam-blog/seam/search.xhtml?searchPattern=book
. This is nice, but Seam can make the URL even simpler using a rewrite rule. The first rewrite rule, for the pattern /search/{searchPattern}
, says that any time we have have a URL for search.xhtml with a searchPattern request parameter, we can fold that URL into the simpler URL. So,the URL we saw earlier, http://localhost:8080/seam-blog/seam/search.xhtml?searchPattern=book
can be written instead as http://localhost:8080/seam-blog/search/book
.
ページパラメータと同様に、URL 書き換えは両方向です。 Seam はより簡単な URL の要求を適切なビューにフォーワードすること、そして簡単なビューを自動的に生成することも意味します。 唯一の要件は URL を書き換えするために、書き換えフィルタが components.xml
において使用可能であることです。
<web:rewrite-filter view-mapping="/seam/*" />
リダイレクトによって search.xhtml
ページに移動します。
<h:dataTable value="#{searchResults}" var="blogEntry">
<h:column>
<div>
<s:link view="/entry.xhtml" propagation="none" value="#{blogEntry.title}">
<f:param name="blogEntryId" value="#{blogEntry.id}"/>
</s:link>
posted on
<h:outputText value="#{blogEntry.date}">
<f:convertDateTime timeZone="#{blog.timeZone}" locale="#{blog.locale}" type="both"/>
</h:outputText>
</div>
</h:column>
</h:dataTable
>
これもまた Hibernate 検索を使用し実際の検索結果を取得するために "PULL" 型 MVC を使用しています。
@Name("searchService")
public class SearchService
{
@In
private FullTextEntityManager entityManager;
private String searchPattern;
@Factory("searchResults")
public List<BlogEntry
> getSearchResults()
{
if (searchPattern==null || "".equals(searchPattern) ) {
searchPattern = null;
return entityManager.createQuery("select be from BlogEntry be order by date desc").getResultList();
}
else
{
Map<String,Float
> boostPerField = new HashMap<String,Float
>();
boostPerField.put( "title", 4f );
boostPerField.put( "body", 1f );
String[] productFields = {"title", "body"};
QueryParser parser = new MultiFieldQueryParser(productFields, new StandardAnalyzer(), boostPerField);
parser.setAllowLeadingWildcard(true);
org.apache.lucene.search.Query luceneQuery;
try
{
luceneQuery = parser.parse(searchPattern);
}
catch (ParseException e)
{
return null;
}
return entityManager.createFullTextQuery(luceneQuery, BlogEntry.class)
.setMaxResults(100)
.getResultList();
}
}
public String getSearchPattern()
{
return searchPattern;
}
public void setSearchPattern(String searchPattern)
{
this.searchPattern = searchPattern;
}
}
ごく希に、RESTful ページ処理のために PUSH 型 MVC を使用することが当然の場合があります。 そこで、Seam は、ページアクション の概念を提供します。 Blog サンプルは、 Blog 記入ページ、 entry.xhtml
にページアクションを使用しています。 これは、少しわざとらしい感じで、ここでは、PULL 型 MVC を使用する方が容易かもしれません。
entryAction
コンポーネントは、 Struts のような典型的な PUSH 型 MVC アクション指向フレームワークのように動作します。
@Name("entryAction")
@Scope(STATELESS)
public class EntryAction
{
@In Blog blog;
@Out BlogEntry blogEntry;
public void loadBlogEntry(String id) throws EntryNotFoundException
{
blogEntry = blog.getBlogEntry(id);
if (blogEntry==null) throw new EntryNotFoundException(id);
}
}
ページアクションは、pages.xml
でも宣言されます。
<pages>
...
<page view-id="/entry.xhtml"
>
<rewrite pattern="/entry/{blogEntryId}" />
<rewrite pattern="/entry" />
<param name="blogEntryId"
value="#{blogEntry.id}"/>
<action execute="#{entryAction.loadBlogEntry(blogEntry.id)}"/>
</page>
<page view-id="/post.xhtml" login-required="true">
<rewrite pattern="/post" />
<action execute="#{postAction.post}"
if="#{validation.succeeded}"/>
<action execute="#{postAction.invalid}"
if="#{validation.failed}"/>
<navigation from-action="#{postAction.post}">
<redirect view-id="/index.xhtml"/>
</navigation>
</page>
<page view-id="*">
<action execute="#{blog.hitCount.hit}"/>
</page>
</pages
>
このサンプルはポストバリデーションとページビューカウンタのためにページアクションを使用していことに留意してください。 同様にページアクションメソッドバインディングでのパラメータの使用にも留意してください。 これは標準 JSF EL の機能ではありませんが、Seam はページアクションだけでなく JSF メソッドバインディングでも使用を可能にしています。
When the entry.xhtml
page is requested, Seam first binds the page parameter blogEntryId
to the model. Keep in mind that because of the URL rewriting, the blogEntryId parameter name won't show up in the URL. Seam then runs the page action, which retrieves the needed data—the blogEntry
—and places it in the Seam event context. Finally, the following is rendered:
<div class="blogEntry">
<h3
>#{blogEntry.title}</h3>
<div>
<s:formattedText value="#{blogEntry.body}"/>
</div>
<p>
[Posted on 
<h:outputText value="#{blogEntry.date}">
<f:convertDateTime timeZone="#{blog.timeZone}" locale="#{blog.locale}" type="both"/>
</h:outputText
>]
</p>
</div
>
blog エントリがデータベースで見つからない場合、 EntryNotFoundException
例外がスローされます。 exception is thrown. この例外は 505 エラーではなく 404 であって欲しいので、 例外クラスのアノテーションを付けます。
@ApplicationException(rollback=true)
@HttpError(errorCode=HttpServletResponse.SC_NOT_FOUND)
public class EntryNotFoundException extends Exception
{
EntryNotFoundException(String id)
{
super("entry not found: " + id);
}
}
別実装のサンプルは、メソッドバインディングでパラメータを使用しません。
@Name("entryAction")
@Scope(STATELESS)
public class EntryAction
{
@In(create=true)
private Blog blog;
@In @Out
private BlogEntry blogEntry;
public void loadBlogEntry() throws EntryNotFoundException
{
blogEntry = blog.getBlogEntry( blogEntry.getId() );
if (blogEntry==null) throw new EntryNotFoundException(id);
}
}
<pages>
...
<page view-id="/entry.xhtml" action="#{entryAction.loadBlogEntry}">
<param name="blogEntryId" value="#{blogEntry.id}"/>
</page>
...
</pages
>
どの実装を選択するかは好みの問題です。
ブログデモはまたとても簡単なパスワード認証、ブログのポスト、ページの一部のキャッシュ、 atom フィードの生成も実演しています。
Seam ディストリビューションはコマンドラインユーティリティを含んでおり、 Eclipse プロジェクトのセットアップ、 Seam のスケルトンコードの生成、 既存データベースからアプリケーションのリバースエンジニアリングをとても簡単にします。
これは、Seam 入門として良い方法です。 そして、状態をデータベースに保管するとてもつまらないアプリケーションを構築するために、 新しいおもちゃがどれほどすばらしいかを大げさに話す退屈な Ruby 野郎の一人に次にエレベータの中で捕まったとわかった時のために、 攻撃材料を与えてくれます。
このリリースでは、seam-gen は JBoss AS で使用するのが最良です。 プロジェクト設定をマニュアルで少し変更するだけで、生成されたプロジェクトを他の J2EE や Java 5 アプリケーションサーバー用にも使用可能です。
Eclipse がなくても seam-gen は使用可能ですが、このチュートリアルでは Eclipse を使用してデバッグや統合テストを行う方法を示したいと思います。 Eclipse をインストールしたくない方も、 このチュートリアルを続けることができます — コマンドラインからすべてのステップは実行可能です。
Seam-gen は簡単に言ってしまえば、テンプレートと共に提供される Hibernate Tools をラッピングした大きな醜い Ant スクリプトです。 これは必要であれば簡単にカスタマイズできることを意味します。
始める前に、JDK 5 または JDK 6 ( 詳細は 項40.1. 「JDK の依存性」 参照 ) と JBoss AS 4.2 と Ant 1.6 そして、それに合う Eclipse 用の JBoss IDE プラグイン と TestNG プラグインがインストールされていることを確認してください。 Eclipse の JBoss サーバビューに JBoss 設定を追加してください。 デバッグモードで JBoss を起動してください。 最後に、Seam ディストリビューションを展開したディレクトリでコマンドプロンプト起動してください。
JBoss は WAR や EAR の優れたホット再デプロイメントをサポートします。 残念ながら、 JVM にバグがあるため、 — 開発段階では一般的な — EAR の再デプロイメントを繰り返すと最終的には JVM が perm gen スペースを使い果たしてしまうことになります。 この理由により、デプロイメント時に perm gen space を大きく確保した JVM で JBoss を稼動させることを推奨します。 JBoss IDE から JBoss を稼動させる場合は、 「VM 引数」の下にあるサーバ起動設定でこれを設定することができます。 以下のような値を推奨します。
-Xms512m -Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=512
十分なメモリがない場合には、以下が最小の推奨値です。
-Xms256m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=256
コマンドラインから JBoss を起動しているならば、 bin/run.conf
の JVM オプション設定が可能です。
今すぐに変更を行いたくない場合は特に行う必要はありません — OutOfMemoryException
が発生した時点で対処してください。
最初にすべきことはあなたの環境用に seam-gen を設定することです。 ( JBoss AS インストールディレクトリ、Eclipse ワークスペース、データベースコネクション ) それは簡単です。以下のようにタイプしてください。
cd jboss-seam-2.1.x seam setup
以下のように必要な情報の入力を要求されるでしょう。
~/workspace/jboss-seam$ ./seam setup Buildfile: build.xml init: setup: [echo] Welcome to seam-gen :-) [input] Enter your Java project workspace (the directory that contains your Seam projects) [C:/Projects] [C:/Projects] /Users/pmuir/workspace [input] Enter your JBoss home directory [C:/Program Files/jboss-4.2.2.GA] [C:/Program Files/jboss-4.2.2.GA] /Applications/jboss-4.2.2.GA [input] Enter the project name [myproject] [myproject] helloworld [echo] Accepted project name as: helloworld [input] Select a RichFaces skin (not applicable if using ICEFaces) [blueSky] ([blueSky], classic, ruby, wine, deepMarine, emeraldTown, sakura, DEFAULT) [input] Is this project deployed as an EAR (with EJB components) or a WAR (with no EJB support) [ear] ([ear], war, ) [input] Enter the Java package name for your session beans [com.mydomain.helloworld] [com.mydomain.helloworld] org.jboss.helloworld [input] Enter the Java package name for your entity beans [org.jboss.helloworld] [org.jboss.helloworld] [input] Enter the Java package name for your test cases [org.jboss.helloworld.test] [org.jboss.helloworld.test] [input] What kind of database are you using? [hsql] ([hsql], mysql, oracle, postgres, mssql, db2, sybase, enterprisedb, h2) mysql [input] Enter the Hibernate dialect for your database [org.hibernate.dialect.MySQLDialect] [org.hibernate.dialect.MySQLDialect] [input] Enter the filesystem path to the JDBC driver jar [lib/hsqldb.jar] [lib/hsqldb.jar] /Users/pmuir/java/mysql.jar [input] Enter JDBC driver class for your database [com.mysql.jdbc.Driver] [com.mysql.jdbc.Driver] [input] Enter the JDBC URL for your database [jdbc:mysql:///test] [jdbc:mysql:///test] jdbc:mysql:///helloworld [input] Enter database username [sa] [sa] pmuir [input] Enter database password [] [] [input] skipping input as property hibernate.default_schema.new has already been set. [input] Enter the database catalog name (it is OK to leave this blank) [] [] [input] Are you working with tables that already exist in the database? [n] (y, [n], ) y [input] Do you want to drop and recreate the database tables and data in import.sql each time you deploy? [n] (y, [n], ) n [input] Enter your ICEfaces home directory (leave blank to omit ICEfaces) [] [] [propertyfile] Creating new property file: /Users/pmuir/workspace/jboss-seam/seam-gen/build.properties [echo] Installing JDBC driver jar to JBoss server [echo] Type 'seam create-project' to create the new project BUILD SUCCESSFUL Total time: 1 minute 32 seconds ~/workspace/jboss-seam $
このツールは気の利いたデフォルト値を提供します。 プロンプトに対して単に enter を押すだけで大丈夫です。
決める必要がある重要な選択は、プロジェクトとして EAR 形式デプロイと WAR 形式デプロイのどちらにするかです。 EAR プロジェクトは EJB 3.0 に対応し Java EE 5 が必要です。 WAR プロジェクトは EJB 3.0 には対応しませんが J2EE 環境にデプロイ可能になります。 WAR は EAR に比べシンプルで理解しやすいパッケージです。 JBoss のような EJB3 が実行可能なアプリケーションサーバーにインストールする場合は ear
を選択してください。 これ以外は war
を選択してください。 以降、 このチュートリアルでは EAR デプロイメントが選択されたと仮定しますが、 WAR デプロイメントの場合もまったく同じステップで進むことができます。
既存のデータモデルで作業をしている場合、 データベースに既にテーブルが存在していることを seam-gen に必ず知らせてください。
設定は seam-gen/build.properties
に格納されていますが、 二度目に seam setup
を実行することで変更することも可能です。
以下のようにタイプすることで、Eclipse ワークスペースディレクトリに、 新規プロジェクトの生成が可能です。
seam new-project
C:\Projects\jboss-seam>seam new-project Buildfile: build.xml ... new-project: [echo] A new Seam project named 'helloworld' was created in the C:\Projects directory [echo] Type 'seam explode' and go to http://localhost:8080/helloworld [echo] Eclipse Users: Add the project into Eclipse using File > New > Project and select General > Project (not Java Project) [echo] NetBeans Users: Open the project in NetBeans BUILD SUCCESSFUL Total time: 7 seconds C:\Projects\jboss-seam>
Seam jar、依存する jar そして JDBC ドライバ jar を新しい Eclipse プロジェクトにコピーし、 Eclipse メタデータおよび Ant ビルドスクリプトに従って必要となるすべてのリソースと設定ファイル群、 facelets テンプレートファイル、 スタイルシートを生成します。 新規 -> プロジェクト... -> 一般 -> プロジェクト -> 次へ
の手順でプロジェクトを追加し、 プロジェクト名
(この場合、 helloworld
) を入力して、 完了
をクリックすれば、 Eclipse プロジェクトは自動的に展開された JBoss AS ディレクトリ構造にデプロイされます。 新規プロジェクトウィザードから Java プロジェクト
は選択しないでください。
Eclipse のデフォルト JDK が Java SE 5 あるいは Java SE 6 の JDK でなければ、 プロジェクト -> プロパティ -> Java コンパイラ
の手順で、Java SE 5 互換の JDK を選ぶ必要があります。
別の方法として、Eclise の外部から seam explode
とタイプすることでプロジェクトのデプロイが可能です。
welcome page を見るには、http://localhost:8080/helloworld
に進んでください。 これは、テンプレート view/layout/template.xhtml
を使用した facelets page, view/home.xhtml
です。 Eclipse からこのページやテンプレートの編集が可能です。 そしてブラウザを更新することで即座に結果を見ることが可能です。
プロジェクトディレクトリに XML 設定ドキュメントが生成されますがびっくりしないでください。 これらのほとんどが標準 Java EE に関するもので、 一度生成したら 二度と見る必要のないものです。 全 Seam プロジェクトで 90% は同じものです。 (seam-gen ができるほどですから記述が非常に簡単なドキュメントです。)
生成されたプロジェクトは三つのデータベースと永続性設定を含んでいます。 HSQLDB に対して TestNG ユニットテストを実行するときに persistence-test.xml
と import-test.sql
ファイルが使用されます。 import-test.sql
中のデータベーススキーマとテストデータは常にテストが実行される前にデータベースにエキスポートされます。 myproject-dev-ds.xml
、persistence-dev.xml
と import-dev.sql
はアプリケーションを開発データベースにデプロイするときに使用します。 seam-gen に既存データベースで作業しているかを伝えるかどうかによってスキーマはデプロイ時に自動的にエキスポートされる場合があります。 myproject-prod-ds.xml
、 persistence-prod.xml
と import-prod.sql
ファイルは、 本番環境データベースにアプリケーションをデプロイするときに使用します。 デプロイ時にスキーマは自動的にエキスポートされません。
従来のアクションスタイルの Web フレームワークに慣れている場合、 おそらくどのように Java のステートレスアクションメソッドを持つ簡単な Web ページが生成されるのだろうかと思われるでしょう。 以下のようにタイプしてください。
seam new-action
Seam は情報のために質問をしてきます。そして、プロジェクトのための新しい facelets page や Seam コンポーネントを生成します。
C:\Projects\jboss-seam>seam new-action Buildfile: build.xml validate-workspace: validate-project: action-input: [input] Enter the Seam component name ping [input] Enter the local interface name [Ping] [input] Enter the bean class name [PingBean] [input] Enter the action method name [ping] [input] Enter the page name [ping] setup-filters: new-action: [echo] Creating a new stateless session bean component with an action method [copy] Copying 1 file to C:\Projects\helloworld\src\hot\org\jboss\helloworld [copy] Copying 1 file to C:\Projects\helloworld\src\hot\org\jboss\helloworld [copy] Copying 1 file to C:\Projects\helloworld\src\hot\org\jboss\helloworld\test [copy] Copying 1 file to C:\Projects\helloworld\src\hot\org\jboss\helloworld\test [copy] Copying 1 file to C:\Projects\helloworld\view [echo] Type 'seam restart' and go to http://localhost:8080/helloworld/ping.seam BUILD SUCCESSFUL Total time: 13 seconds C:\Projects\jboss-seam>
新しい Seam コンポーネントを追加したので、 展開したディレクトリのデプロイを再起動する必要があります。 seam restart
と入力するか、 Eclipse 内から生成されたプロジェクト build.xml ファイル の restart
ターゲットを実行することで行うことができます。 再起動を強制する別の方法は Eclipse の resources/META-INF/application.xml
ファイルを編集することです。 アプリケーションを変更するたびに JBoss を再起動する必要はないことに留意してください。
さあ、http://localhost:8080/helloworld/ping.seam
に進んで、クリックボタンを押してください。 プロジェクトの src
directory ディレクトリを見れば、このアクションに隠されたコードを見ることができます。 ping()
メソッドにブレークポイントを置いて、 クリックボタンを押してください。
最後に、PingTest.xml
ファイルを test パッケージに配置し、 Eclipse の TestNG プラグインを使用して統合テストを実行します。 別な方法として、 seam test
を使用してテストを起動するか、 生成されたビルドから test
ターゲットを起動します。
次のステップは、以下のようにフォームを生成することです。
seam new-form
C:\Projects\jboss-seam>seam new-form Buildfile: C:\Projects\jboss-seam\seam-gen\build.xml validate-workspace: validate-project: action-input: [input] Enter the Seam component name hello [input] Enter the local interface name [Hello] [input] Enter the bean class name [HelloBean] [input] Enter the action method name [hello] [input] Enter the page name [hello] setup-filters: new-form: [echo] Creating a new stateful session bean component with an action method [copy] Copying 1 file to C:\Projects\hello\src\hot\com\hello [copy] Copying 1 file to C:\Projects\hello\src\hot\com\hello [copy] Copying 1 file to C:\Projects\hello\src\hot\com\hello\test [copy] Copying 1 file to C:\Projects\hello\view [copy] Copying 1 file to C:\Projects\hello\src\hot\com\hello\test [echo] Type 'seam restart' and go to http://localhost:8080/hello/hello.seam BUILD SUCCESSFUL Total time: 5 seconds C:\Projects\jboss-seam>
再びアプリケーションを再起動させ、 http://localhost:8080/helloworld/hello.seam
に進みます。 生成されたコードを見てみましょう。 テストを実行します。 何か新しいフィールドをフォームと Seam コンポーネントに追加してみましょう。 (Java コードを変更したら常にデプロイを再起動することを忘れないようにしてください。)
手動でデータベースの中にテーブルを生成します。 (別のデータベースに切り替える必要がある場合はもう一度 seam setup
を実行します。) ここで次のように入力します。
seam generate-entities
デプロイを再起動して、 http://localhost:8080/helloworld
に進んでください。 データベースの参照、 既存オブジェクトの編集、 新しいオブジェクトの生成が可能です。 生成されたコードを見ると、おそらくあまりに簡単なのに驚かれたと思います。 Seam はデータアクセスコードが手作業で簡単に記述できるように設計されているからです。 また seam-gen を使用したずるをしたくない人でも大丈夫です。
既存の有効なエンティティクラスを src/main
に置いて、以下をタイプしてください。
seam generate-ui
デプロイメントをリスタートして、http://localhost:8080/helloworld
に進んでください。
最後に、 標準の Java EE 5 パッケージングを使用してアプリケーションをデプロイできるようにしたいと思います。 まず、 seam unexplode
を実行して展開したディレクトリを削除する必要があります。 EAR をデプロイするには、 コマンドプロンプトで seam deploy
を入力するか、 あるいは生成されたプロジェクトの build スクリプトの deploy
ターゲットを実行します。 seam undeploy
または undeploy
ターゲットを使うとアンデプロイができます。
デフォルトでは、アプリケーションは dev profile でデプロイされます。 EAR は persistence-dev.xml
ファイルと import-dev.sql
ファイルを含み、 myproject-dev-ds.xml
ファイルがデプロイされます。 プロファイルは変更可能で、 以下のように入力して prod profile を使用します。
seam -Dprofile=prod deploy
アプリケーション用に新しいデプロイメントプロファイルを定義することもできます。 プロジェクトに適切な名前が付いたファイルを追加します — 例えば、persistence-staging.xml
、import-staging.sql
と myproject-staging-ds.xml
などです。 -Dprofile=staging
を使ってプロファイルの名前を選択します。
展開形式のディレクトリで Seam アプリケーションをデプロイする場合、 開発時に増分ホットデプロイのサポートを受けるでしょう。 components.xml
に以下の行を追加することで、 Seam と Facelets の両方でデバッグモードを有効にする必要があります。
<core:init debug="true"
>
以下のファイルは、 Webアプリケーションを完全に再起動することなく置き換えがされるかもしれません。
facelets ページ
pages.xml
ファイル
ただし、 いずれかの Java コードを変更する必要がある場合は、 アプリケーションを完全に再起動する必要があります。 (JBoss ではトップレベルのデプロイメント記述子を更新することでこれを行えます。 EAR デプロイメントなら application.xml
、 WAR デプロイメントなら web.xml
です。)
しかし、 早いペースの編集/コンパイル/テストのサイクルを望むならば、 Seam は JavaBean コンポーネントの増分再デプロイメントをサポートしています。 この機能を有効にするためには、 JavaBean コンポーネントを WEB-INF/dev
ディレクトリにデプロイする必要があります。 その結果、コンポーネントは WAR あるいは EAR クラスローダではなく、 特殊な Seam クラスローダによってロードされるようになります。
以下の制約を知っている必要があります。
コンポーネントは JavaBean コンポーネントでなければならず、 EJB3 Bean は不可です。 (この制約は修正中です。)
エンティティはホットデプロイされることはありません。
components.xml
でデプロイされたコンポーネントはホットデプロイできない場合があります。
ホットデプロイ可能なコンポーネントは、 WEB-INF/dev
の外部にデプロイされたクラスからは見えません。
Seam デバッグモードは有効で jboss-seam-debug.jar
は WEB-INF/lib
になければなりません。
web.xml に Seam フィルタをインストールしなければなりません。
ロードとデバッグが有効な環境のシステムであればエラーが発生するかもしれません。
seam-gen を使用して WAR プロジェクトを生成する場合、 増分ホットデプロイメントは、src/hot
ソースディレクトリにあるクラスにそのまま使用可能です。 しかしながら、 seam-gen は EAR プロジェクトに対する増分ホットデプロイに対応していません。
Seam 2.0 は JavaServer Faces 1.2 にデプロイされます。 JBoss AS を使用するならば、JBoss 4.2 を使用することを推奨します。 これは JSF 1.2 リファレンス実装がバンドルされています。 でも JBoss 4.0 プラットフォームで Seam 2.0 を使用することも可能です。 これを行うには 2 つの基本的なステップが必要です。 EJB3 が有効なバージョンの JBoss 4.0 のインストール、 MyFaces を JSF 1.2 リファレンス実装に交換。 これらのステップを行えば、Seam 2.0 アプリケーションは JBoss 4.0 にデプロイ可能になります。
JBoss 4.0 は Seam 互換のデフォルト設定で出荷されていません。 Seam を実行するために EJB3 プロファイルを選択して JEMS 1.2 インストーラ を使用してインストールしなければなりません。 Seam は EJB3 サポートを含まないインストールでは動作しません。 JEMS インストーラは http://labs.jboss.com/jemsinstaller/downloads からダウンロード可能です。
JBoss 4.0 の Web 設定は server/default/deploy/jbossweb-tomcat55.sar
にあります。 jsf-libs
ディレクトリから myfaces-api.jar
と myfaces-impl.jar
を削除する必要があります。 そして、ディレクトリに jsf-api.jar
、jsf-impl.jar
、el-api.jar
と el-ri.jar
をコピーする必要があります。 JSF の JAR は Seam lib
ディレクトリにあります。 el の JAR は Seam 1.2 リリースから取得可能です。
さらに conf/web.xml
を編集する必要があります。 myfaces-impl.jar
を jsf-impl.jar
に交換してください。
JBoss Tools は Eclipse プラグインを集めたものです。 JBoss Tools は Seam プロジェクト作成ウィザード、facelets と Java コードの Unified Expression Language (EL) のための入力補助、jPDLのためのグラフィックエディタ、Seam 設定ファイルのためのグラフィックエディタ、Eclipse から Seam 統合テストの実行サポートなどです。
端的にいえば、Eclipse ユーザーであれば、JBoss Tools を必要とするでしょう。
seam-gen 同様 JBoss Tools は JBoss AS と動作させるのが好ましいのですが、わずかに変更することで他のアプリケーションサーバーでも動作させることが可能です。 変更はこのリファレンスマニュアル中の seam-gen の記述と似ています。
開始前に JDK 5、JBoss AS 4.2、Eclipse 3.3、the JBoss Tools プラグイン ( 最低限、Seam Tools、Visual Page Editor、jBPM Tools と JBoss AS Tools) そして TestNG プラグイン for Eclipse がきちんとインストールされていることを確認してください。
TODO - アップデートサイトがどこであるかの詳細
Eclipse を起動して Seam パースペクティブを選択してください。
File -> New -> Seam Web Project とすすめます。
最初に、プロジェクト名を登録します。 このチュートリアルでは helloworld
とします。
次に、JBoss Tools に JBoss AS について指定します。 これは 二段階のプロセスです。 最初にランタイムを定義します。 JBoss AS 4.2 を選択してください。
ランタイムの名前を登録し、ハードディスク上の位置を指定します。
次に、JBoss Tools がプロジェクトをデプロイ可能なサーバを定義する必要があります。 ここでも JBoss AS 4.2 と直前で定義したランタイムを選択してください。
次のサーバに名前をつける画面では、Finish を押してください。
いま作成と選択をしたランタイムとサーバを確認して、Dynamic Web Project with Seam 2.0 (technology preview) を選択して Next を押してください。
The next 3 screens allow you to further customize your new project, but for us the defaults are fine. So just hit <empahsis>Next</empahsis> until you reach the final screen.
最初のステップは JBoss Tools を使用する上で必要な Seam ランタイムを指定します。 新しい Seam Runtime を追加します。 - 名前をつけて、バージョンとして 2.0 を選択してください。
決める必要がある重要な選択は、プロジェクトとして EAR 形式デプロイと WAR 形式デプロイのどちらにするかです。 EAR プロジェクトは EJB 3.0 に対応し Java EE 5 が必要です。 WAR プロジェクトは EJB 3.0 には対応しませんが、く J2EE 環境にデプロイ可能です。 WAR は EAR に比べシンプルで理解しやすいパッケージです。 JBoss のような EJB3 が実行可能なアプリケーションサーバーにインストールする場合は EAR
を選択してください。 これ以外は WAR
を選択してください。 以降、 このチュートリアルでは WAR デプロイメントが選択されたと仮定しますが、 EAR デプロイメントの場合もまったく同じステップで進むことができます。
次に、データベースのタイプを選択します。 ここでは既存のスキーマを持つ MySQL がインストールされていることを前提とします。 JBoss Tools にデータベースについて指定する必要があります、データベースとして MySQL を選択して、新たにコネクションプロファイルを作成してください。 Generic JDBC Connection を選択してください。
名前をつけてください。
JBoss Tools はデータベースドライバを持っていないので、JBoss Tools にどこに MySQL JDBC があるかを指定する必要があります。 クリックしてドライバに関して指定してください。
MySQL 5 の場所で、Add... を押してください。
MySQL JDBC Driver テンプレートを選択してください。
Edit Jar/Zip を選択することでコンピュータ上の jar の位置を指定してください。
接続のためのユーザー名とパスワードを確認して正しければ、Ok を押してください。
最後に新規に作成されたドライバを選択してください。
既存のデータモデルで作業をしている場合、 データベースに既にテーブルが存在していることを JBoss Tools に必ず知らせてください。
接続のためのユーザー名とパスワードを確認して、Test Connection ボタンを使用して接続をテストします。 動作したならば、Finish を押します。
最後に、生成された Bean のパッケージ名を確認して、問題なければ、Finish をクリックします。
JBoss は WAR や EAR の優れたホット再デプロイメントをサポートします。 残念ながら、 JVM にバグがあるため、 — 開発段階では一般的な — EAR の再デプロイメントを繰り返すと最終的には JVM が perm gen スペースを使い果たしてしまうことになります。 この理由により、デプロイメント時に perm gen space を大きく確保した JVM で JBoss を稼動させることを推奨します。 以下のような値を推奨します。
-Xms512m -Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=512
十分なメモリがない場合には、以下が最小の推奨値です。
-Xms256m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=256
JBoss Server View にサーバを配置し、サーバの上で右クリックして Edit Launch Configuration を選択してください。
そして、VM 引数を変更してください。
今すぐに変更を行いたくない場合は特に行う必要はありません — OutOfMemoryException
が発生した時点で対処してください。
JBoss の起動、プロジェクトのデプロイのためには、作成したサーバの上の右クリックして Start をクリックしてください。 また、デバッグモードで起動するには Debug をクリックしてください。
プロジェクトディレクトリに XML 設定ドキュメントが生成されますがびっくりしないでください。 これらのほとんどが標準 Java EE に関するもので、 一度生成したら 二度と見る必要のないものです。 すべての Seam プロジェクトで 90% は同じものです。
従来のアクションスタイルの Web フレームワークに慣れている場合、 おそらくどのように Java のステートレスアクションメソッドを持つ簡単な Web ページが生成されるのだろうかと思われるでしょう。
最初に、New -> Seam Action と選択してください。
ここでは、Seam コンポーネント名を登録してください。 JBoss Tools は他のフィールドのために気の利いたデフォルトを選択します。
最後に Finish を押します。
さあ、http://localhost:8080/helloworld/ping.seam
に進んで、クリックボタンを押してください。 プロジェクトの src
directory ディレクトリを見れば、このアクションに隠されたコードを見ることができます。 ping()
メソッドにブレークポイントを置いて、 クリックボタンを押してください。
最後に、helloworld-test
プロジェクトを開いて、PingTest
クラスを指定して、それを右クリックして、Run As -> TestNG Test と選択してください。
最初のステップはフォームを生成することです。 New -> Seam Form と選択してください。
ここでは、Seam コンポーネント名を登録してください。 JBoss Tools は他のフィールドのために気の利いたデフォルトを選択します。
http://localhost:8080/helloworld/hello.seam
と進んでください。 そして生成されたコードを見てください。 テストを起動してください。 フォームと Seam コンポーネントに新しいフィールドを追加してみてください。(Seam がコンポーネントをホットリロード 項3.6. 「Seam と JBoss Tools を使用した増分ホットデプロイメント」 するので、 src/hot
のコードを変更するたびにアプリケーションサーバーをリスタートする必要がないことに留意してください。)
手動でデータベースの中にテーブルを生成します。 (別のデータベースに切り替える必要がある場合、新たなプロジェクトを作成して、正しいデータベースを選択してください。) そして、New -> Seam Generate Entities と選択します。
JBoss Tools には、データベーススキーマからエンティティ、コンポーネント、ビューのリバースエンジニアリングをするか、あるいは既存 JPA エンティティからコンポーネントとビューのリバースエンジニアリングをするかのオプションがあります。 ここではデータベースからのリバースエンジニアリングを行います。
デプロイメントの再起動:
http://localhost:8080/helloworld
にすすんでください。 データベースをブラウズ、既存オブジェクトの編集、そして新規オブジェクトの作成が可能です。 生成されたコードを見ると、何てシンプルなんだと驚かれるはずです! Seam はマニュアルで簡単にデータアクセスコードが書けるよう設計されています。 リバースエンジニアリングを使用したカンニングをしたくない人にも簡単です。
JBoss Tools は以下について増分ホットデプロイメントをサポートします。
facelets ページ
pages.xml
ファイル
out of the box.
ただし Java コードを変更したいのならば、Full Publish することでアプリケーションを再起動する必要があります。
しかし、 早いペースの編集/コンパイル/テストのサイクルを望むならば、 Seam は JavaBean コンポーネントの増分再デプロイメントをサポートしています。 この機能を有効にするためには、 JavaBean コンポーネントを WEB-INF/dev
ディレクトリにデプロイする必要があります。 その結果、コンポーネントは WAR あるいは EAR クラスローダではなく、 特殊な Seam クラスローダによってロードされるようになります。
以下の制約を知っている必要があります。
コンポーネントは JavaBean コンポーネントでなければならず、 EJB3 Bean は不可です。 (この制約は修正中です。)
エンティティはホットデプロイできません。
components.xml
でデプロイされたコンポーネントはホットデプロイできない場合があります。
ホットデプロイ可能なコンポーネントは、 WEB-INF/dev
の外部にデプロイされたクラスからは見えません。
Seam デバッグモードは有効で jboss-seam-debug.jar
は WEB-INF/lib
になければなりません。
web.xml に Seam フィルタをインストールしなければなりません。
ロードとデバッグが有効な環境のシステムであればエラーが発生するかもしれません。
JBoss Tools を使用して WAR プロジェクトを生成する場合、 増分ホットデプロイメントは、src/hot
ソースディレクトリにあるクラスはそのまま使用可能です。 しかし、 JBoss Tools は EAR プロジェクトに対する増分ホットデプロイに対応していません。
Seam における 2 つの中心的概念は、 コンテキスト の概念と コンポーネント の概念です。 コンポーネントは、ステートフルなオブジェクト、通常は EJB です。 コンポーネントのインスタンスは、コンテキストと関連づけられ、そのコンテキスト中で名前を与えられます。 バイジェクション (Bijection) は、内部のコンポーネント名 (インスタンス変数) をコンテキスト中の名前にエイリアスし、 Seam によるコンポーネントツリーの動的な組み立て、再組み立てを可能にするメカニズムを提供します。
Seam に組み込まれたコンテキストから説明を始めましょう。
Seam コンテキストはフレームワークによって生成、破棄されます。 アプリケーションは Java API 呼び出しによってコンテキストの区分 (demarcation) を明示的に制御することはできません。 コンテキストは通常、暗黙的ですが、場合によってコンテキストはアノテーションによって区分されます。
基本の Seam コンテキストは以下の通りです。
ステートレスコンテキスト
Event (or request) context
ページコンテキスト
対話コンテキスト
セッションコンテキスト
ビジネスプロセスコンテキスト
アプリケーションコンテキスト
これらのコンテキストのいくつかは、サーブレットや関連する仕様に由来していることがわかります。 しかし、このうち 2 つは目新しいかもしれません。 対話コンテキスト (conversation context) とビジネスプロセスコンテキストです。 Web アプリケーション中での状態管理がとても脆弱でエラーが発生しやすい 1 つの理由は、 3 つの組み込みコンテキスト (要求、セッション、アプリケーション) がビジネスロジックの観点から特定の意味を持たないからです。 例えば、実際のアプリケーションのワークフローの観点から見るとユーザーログインセッションは極めて自由裁量な構造です。 そのため、ほとんどの Seam コンポーネントは、対話コンテキストあるいはビジネスプロセスコンテキストのスコープに配置されます。 なぜなら、それらはアプリケーションの観点からとても意味のあるコンテキストだからです。
順に、それぞれのコンテキストを見ていきましょう。
Components which are truly stateless (stateless session beans, primarily) always live in the stateless context (this is really a non-context). Stateless components are not very interesting, and are arguably not very object-oriented. Nevertheless, they are important and often useful.
イベントコンテキストは「最も狭い」状態を持つコンテキストで、 他の種類のイベントを網羅する Web 要求コンテキストの概念の一般化です。 それにもかかわらず、JSF 要求のライフサイクルと関連づけられたイベントコンテキストは、 イベントコンテキストの最も重要な用例であり、最もよく利用されるものです。 要求終了時に、イベントコンテキストに関連するコンポーネントは破棄されますが、 それらの状態は、少なくとも要求のライフサイクルの間では有効かつ明確です。
RMI 経由あるいは Seam Remoting により Seam コンポーネントを呼び出すとき、 イベントコンテキストは、その呼び出しだけのために生成、破棄されます。
ページコンテキストは、レンダリングされたページの特定のインスタンスと状態との関連づけを可能にします。 イベントリスナー内で状態の初期化が可能で、 実際にページをレンダリングしている間に、 ページに由来するどんなイベントからも状態にアクセスが可能です。 これは特にサーバサイドのデータ変化にリストが連動しているクリッカブルリストのような機能に役立ちます。 状態は実際にはクライアントのためにシリアライズされます。 そのため、この構造は複数ウインドの操作や戻るボタンに対して極めて堅牢です。
対話コンテキストは Seam でまさに中心となるコンセプトです。 対話 (conversation) は、ユーザーの観点からの作業単位です。 それはユーザーとのインタラクション、要求、およびデータベーストランザクションをまたぐかもしれません。 しかし、ユーザーにとって対話は、1 つの問題を解決します。 例えば、「ホテル予約」、「契約承認」、「注文作成」はすべて対話です。 対話というものが 1 つの「ユースケース」あるいは「ユーザーストーリ」を実装していると考えたいかもしれませんが、関係は必ずしもその通りにはなりません。
対話は、「ユーザーがこのウィンドウの中で現在していること」と関連づけられた状態を保持します。 1 人のユーザーは、通常マルチウィンドウで、ある時点に進行中の複数の対話を持っているかもしれません。 対話コンテキストは、異なる対話からの状態の衝突をなくし、バグの原因とならないことを保証します。
対話の観点からアプリケーションについて考えることに慣れるには時間がかかるかもしれません。 しかし、慣れてしまうと、このコンセプトが大好きになり、もう対話なしでは考えられなくなるだろうと思います。
ある対話は単に 1 つの要求の間続いています。 複数の要求をまたぐ対話は、Seam によって提供されたアノテーションを使って、区分を示されなければなりません。
一部の対話は タスク でもあります。 タスクは長期ビジネスプロセスの観点では重要な意味を持つ対話であり、 タスクが首尾よく完了する場合、 ビジネスプロセスの状態遷移を引き起こす可能性を持っています。 Seam はタスク区分用に特別なアノテーションのセットを提供します。
より広い対話の "内部" で対話を発生させるような ネスト も可能です。 これは拡張機能です。
通常、実際には要求と要求の間サーブレットセッション中で Seam により対話状態は保持されます。 Seam は設定可能な 対話タイムアウト (conversation timeout) を実装し、 自動的に不活性な対話を破棄し、 ユーザーが対話を中断しても、ユーザーログインセッションにより保持される状態は際限なく増加しないことが保証されています。
Seam は同じプロセス中の同じ長期対話コンテキスト中で発生する並列の要求処理をシリアル化します。
あるいは、Seam はクライアントブラウザの中に対話の状態を保持するように設定される場合もあります。
セッションコンテキストはユーザーログインに関する状態を保持します。 いくつかの場合では対話の間で状態を共有することが有用なことがありますが、 ログインユーザーに関するグローバル情報以外のコンポーネントを保持するために、 セッションコンテキストを使用することは賛成できません。
JSR-168 ポータル環境では、セッションコンテキストはポートレットセッションを意味します。
ビジネスプロセスコンテキストは長期ビジネスプロセスに関する状態を保持します。 この状態は BPM エンジン (JBoss jBPM) によって管理や永続化が行われます。 ビジネスプロセスは、複数ユーザーの複数インタラクションを橋渡しします。 従って、この状態は複数ユーザーの間で明確な方法で共有されます。 現在のタスクは現在のビジネスプロセスインスタンスを決定し、 ビジネスプロセスのライフサイクルは プロセス定義言語 (process definition language) を使用することで外部に定義されます。 従って、ビジネスプロセスの区分のために特別なアノテーションはありません。
アプリケーションコンテキストはサーブレット仕様からおなじみのサーブレットのコンテキストです。 アプリケーションコンテキストは主に、設定データ、参照データ、メタモデルのような静的な情報を保持するために役立ちます。 例えば、Seam はアプリケーションコンテキスト内に Seam 設定やメタモデルを保管しています。
コンテキストは名前空間、コンテキスト変数 のセットを定義します。 これらはサーブレット仕様のセッションや要求属性と同様に機能します。 どのような値でもコンテキスト変数とバインドができますが、 通常、Seam コンポーネントインスタンスをコンテキスト変数にバインドします。
従って、コンテキスト中では、 コンポーネントインスタンスは、コンテキスト変数名 (いつもではないが通常はコンポーネント名と同じ) で識別されます。 Contexts
クラスを通して特定のスコープの指定されたコンポーネントインスタンスにプログラム的にアクセスもできます。 それは Context
インタフェースのスレッドに結びついたインスタンスへのアクセスを提供します。
User user = (User) Contexts.getSessionContext().get("user");
名前に関連する値を設定したり変更したりすることもできます。
Contexts.getSessionContext().set("user", user);
しかしながら、通常、インジェクションを通してコンテキストからコンポーネントを取得し、 アウトジェクションを通してコンポーネントインスタンスをコンテキストに配置します。
上記のように、コンポーネントインスタンスは特定の周知のスコープから取得することもありますが、 それ以外の場合、すべてのステートフルスコープは 優先順位 に従って検索されます。 その順序は以下の通りです。
イベントコンテキスト
ページコンテキスト
対話コンテキスト
セッションコンテキスト
ビジネスプロセスコンテキスト
アプリケーションコンテキスト
Contexts.lookupInStatefulContexts()
を呼び出すことによって優先順位の検索も可能です。 JSF ページから名前によってアクセスする場合はいつも、優先順位検索が発生します。
サーブレット仕様も EJB 仕様も同じクライアントから起こる同時並行の要求を管理するための仕組みをまったく定義していません。 サーブレットコンテナは単純にすべてのスレッドを同時並行的に稼動させ、 スレッドセーフとすることをアプリケーションコードに任せます。 EJB コンテナはステートレスコンポーネントが同時並行的にアクセスされることを可能にし、 複数のスレッドがひとつのステートレスセッション Bean にアクセスするならば例外をスローします。
この振る舞いは粒度の細かい同期要求をベースとする古いスタイルの Web アプリケーションでは大丈夫であったかもしれません。 しかし、多くの粒度の細かい非同期要求 (AJAX) を多用する最新のアプリケーションにとって、 同時並行はまぎれもない事実であり、プログラムモデルとしてサポートされなければなりません。 Seam は同時並行管理レイヤをコンテキストモデルに織り込みます。
Seam セッションとアプリケーションコンテキストはマルチスレッドになっています。 Seam は同時並行的に処理されるためにコンテキスト中での同時並行要求を許します。 イベントとページコンテキストは本来シングルスレッドです。 厳密に言えばビジネスプロセスコンテキストはマルチスレッドですが、 実際には同時並行はとてもまれで、この事実はほとんど着目されないかもしれません。 最後に、 同じ長期対話コンテキスト中の同時並行要求をシリアライズすることによって、 Seam は、対話コンテキストのために プロセスごと対話ごとのシングルスレッド モデルを実施します。
セッションコンテキストはマルチスレッドで、よく揮発性の状態を含むので、 そのコンポーネントのSeamインタセプタが無効にされていない限り、Seam によりセッションスコープコンポーネントは同時並行アクセスからいつも保護されています。 もしインタセプタが無効にされていたら、要求されるスレッドセーフ性はコンポーネント自身によって実装されなければなりません。Seam はデフォルトで要求を セッションスコープセッション Bean と JavaBean にシリアライズします。 ( そして、発生するどんなデッドロックも検出して打開します。) アプリケーションスコープのコンポーネントは通常揮発性の状態を保持しないため、 これはアプリケーションスコープのコンポーネントのためのデフォルトの振る舞いではありません。 なぜなら、グローバルレベルの同期化は 極端に コストがかかるからです。 しかし、 @Synchronized
アノテーションを追加することで、 セッション Bean または JavaBean コンポーネントにシリアライズされたスレッドモデルを強制可能です。
この同時並行モデルは、 開発者側での特別な作業をまったく必要とすることなく、 AJAX クライアントが安全に揮発性セッションや対話状態を使用できることを意味します。
Seam コンポーネントは POJO (Plain Old Java Objects) です。 具体的には、Seam コンポーネントは JavaBean もしくは EJB 3.0 エンタープライズ Bean です。 Seam は コンポーネントが EJB であることが必須ではなく、また EJB 3.0 準拠のコンテナがなくても使用できますが、 Seam は EJB 3.0 を念頭にして設計され、EJB 3.0 と強く統合されています。 Seam は以下の コンポーネントタイプ をサポートします。
EJB 3.0 ステートレスセッション Bean
EJB 3.0 ステートフルセッション Bean
EJB 3.0 entity beans
JavaBeans
EJB 3.0 メッセージ駆動型 Bean
ステートレスセッション Bean コンポーネントは、複数の呼出しに対して状態を保持することができません。 従って、それらは通常さまざまな Seam コンテキスト内の別コンポーネントの状態を操作するのに役に立ちます。 それらは JSF のアクションリスナーとして使用できるかもしれませんが、 表示のために JSF コンポーネントにプロパティを提供することはできません。
ステートレスセッション Bean はいつもステートレスコンテキストに置かれます。
新しいインスタンスが各要求で使用されるのと同様にステートレスセッション Bean は同時並行的にアクセスされることが可能です。 インスタンスを要求に割り当てることは EJB3 コンテナの責務です。 ( 通常インスタンスは再利用可能なプールから割り当てられます、 つまり、Bean の使用済みのものからデータを含むインスタンス変数を見つけることができることを意味します。)
ステートレスセッション Bean は最も興味のわかない種類の Seam コンポーネントです。
Seam ステートレスセッション Bean コンポーネントは Component.getInstance()
または @In(create=true)
を使用してインスタンス化可能です。これらは JNDI ルックアップや 直接 new オペレータでインスタンス化されるべきではありません。
ステートフルセッション Bean コンポーネントは、 Bean の複数の呼出しに対して状態を保持することができるだけでなく、 複数の要求に対して状態を保持することもできます。 データベースに保持されていないアプリケーションの状態は、 通常、ステートフルセッション Bean によって保持される必要があります。 これは Seam と他の多くの Web アプリケーションフレームワークとの大きな違いです。 現在の対話の情報を直接 HttpSession
に押し込める代わりに、 対話コンテキストに結びついたステートフルセッション Bean のインスタンス変数の中にそれを保持すべきです。 これは、Seam がこの状態のライフサイクルの管理を可能にし、 異なる同時実行中の対話に関連する状態の間に衝突がないことを保証します。
ステートフルセッション Bean はしばしば JSF アクションリスナー、または、 表示もしくはフォームのサブミットのためにプロパティを提供する JSF コンポーネントのバッキング Bean として使用されます。
デフォルトで、ステートフルセッション Bean は対話コンテキストとバインドします。 ページもしくはステートレスコンテキストとバインドできません。
セッションスコープのステートレスセッション Bean への同時並行要求は、 そのBeanへのSeamインタセプタが無効にされていない限り、常に Seam によってシリアライズされます。
Seam ステートフルセッション Bean コンポーネントは Component.getInstance()
または @In(create=true)
を使用してインスタンス化可能です。これらは JNDI ルックアップや 直接 new
オペレータでインスタンス化されるべきではありません。
エンティティ Bean はコンテキスト変数とバインドし、Seamコンポーネントとして機能することもあります。 エンティティは、コンテキスト依存識別子に加えて永続識別子を持つために、 エンティティのインスタンスは、Seam によって暗黙的にインスタンス化されるより、 むしろ Java コード中で明示的にバインドされます。
エンティティ Bean コンポーネントはバイジェクションもコンテキスト区分もサポートしません。 また、エンティティ Bean トリガのデータ妥当性検証の呼び出しもサポートしていません。
エンティティ Bean は、通常 JSF アクションリスナーとして使用されませんが、 しばしば、表示あるいはフォームのサブミットのために JSF コンポーネントにプロパティを提供するバッキング Bean として機能します。 特に、エンティティ Bean をバッキング Bean として使用することは一般的であり、 追加 / 変更 / 削除タイプの機能の実装のためのステートレスセッション Bean アクションリスナーと一緒に使用されます。
デフォルトで、エンティティ Bean は対話コンテキストとバインドします。 ステートレスセッション Bean とはバインドしません。
クラスタリングされた環境では、 ステートフルセッション Bean 中でエンティティ Bean の参照を保持することより、 エンティティ Bean を直接的に対話あるいはセッションスコープの Seam コンテキスト変数にバインドする方が多少非効率的であることに留意してください。 この理由のため、すべての Seam アプリケーションが Seam コンポーネントであるためにエンティティ Bean を定義するわけではありません。
Seam エンティティ Bean コンポーネントは Component.getInstance()
または @In(create=true)
を使用してインスタンス化可能です。あるいは、直接 new
オペレータを使用することが可能です。
JavaBean はステートレスあるいはステートフルセッション Bean のように使用されることもあります。 しかし、それらはセッション Bean の機能を提供していません。 (宣言的トランザクション区分、 宣言的セキュリティ、 効率的にクラスタ化された状態レプリケーション、 EJB 3.0 永続性、 タイムアウトメソッドなど)
後の章で、EJB コンテナなしで Seam や Hibernate を使用する方法を紹介しています。 このユースケースでは、コンポーネントはセッション Bean の代わりに JavaBean です。 しかし、多くのアプリケーションサーバーでは、 ステートフルセッション Bean コンポーネントをクラスタリングするより、 対話あるいはセッションスコープの Seam JavaBean コンポーネントをクラスタリングする方が多少非効率的であることに留意してください。
デフォルトで、JavaBean はイベントコンテキストとバインドします。
セッションスコープの JavaBean への同時並行要求はいつも Seam によりシリアライズされます。
Seam JavaBean コンポーネントは Component.getInstance()
または @In(create=true)
を使用してインスタンス化可能です。これらは直接 new
オペレータでインスタンス化されるべきではありません。
メッセージ駆動形 Bean は Seam コンポーネントとして機能することができます。 しかし、メッセージ駆動型 Bean は、他の Seam コンポーネントとまったく異なった形で呼び出されます。 コンテキスト変数を通じてそれらを呼び出す代わりに、 JMS キュー あるいは、トピックに送信されたメッセージを待ち受けます。
メッセージ駆動形 Bean は、Seam コンテキストとバインドできません。 また、それらの「呼び出し元」のセッションや対話状態にアクセスできません。 しかし、メッセージ駆動形 Bean は、バイジェクションと他の Seam の機能をサポートします。
メッセージ駆動型 Bean はアプリケーションによってインスタンス化されません。これらはメッセージを受信したときに EJB コンテナによってインスタンス化されます。
Seamのマジック (バイジェクション、コンテキスト区分、データ妥当性検証など) を実行するために、 Seam はコンポーネントの呼び出しをインタセプトしなければなりません。 JavaBean では、Seam はコンポーネントのインスタンス化を完全に制御するため、特別な設定は不要です。 エンティティ Bean では、バイジェクションとコンテキスト区分が指定されていないため、インタセプションは不要です。 セッション Bean では、EJB インタセプタをセッション Bean コンポーネントのために登録しなければなりません。 アノテーションは以下のように使用します。
@Stateless
@Interceptors(SeamInterceptor.class)
public class LoginAction implements Login {
...
}
しかし、もっと良い方法は、ejb-jar.xml
にインタセプタを定義することです。
<interceptors>
<interceptor>
<interceptor-class
>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
</interceptor>
</interceptors>
<assembly-descriptor>
<interceptor-binding>
<ejb-name
>*</ejb-name>
<interceptor-class
>org.jboss.seam.ejb.SeamInterceptor</interceptor-class>
</interceptor-binding>
</assembly-descriptor
>
すべての Seam コンポーネントは名前が必要です。 @Name
アノテーションを使用してコンポーネントに名前を割り当てます。
@Name("loginAction")
@Stateless
public class LoginAction implements Login {
...
}
この名前は、Seam コンポーネント名 で、 EJB 標準で定義された他の名前との関連はありません。 しかし、Seam コンポーネント名はちょうど JSF 管理 Bean のように動作するため、 2 つのコンセプトは同一と考えることができます。
@Name
はコンポーネント名を定義する唯一の方法ではありませんが、 いつも、どこかで名前を指定する必要があります。 もしそうしないと、他の Seam アノテーションはどれも機能しないでしょう。
Just like in JSF, a seam component instance is usually bound to a context variable with the same name as the component name. So, for example, we would access the LoginAction
using Contexts.getStatelessContext().get("loginAction")
. In particular, whenever Seam itself instantiates a component, it binds the new instance to a variable with the component name. However, again like JSF, it is possible for the application to bind a component to some other context variable by programmatic API call. This is only useful if a particular component serves more than one role in the system. For example, the currently logged in User
might be bound to the currentUser
session context variable, while a User
that is the subject of some administration functionality might be bound to the user
conversation context variable.
For very large applications, and for built-in seam components, qualified names are often used.
@Name("com.jboss.myapp.loginAction")
@Stateless
public class LoginAction implements Login {
...
}
Java コード中でも JSF の式言語中でも修飾されたコンポーネント名は使用できます。
<h:commandButton type="submit" value="Login"
action="#{com.jboss.myapp.loginAction.login}"/>
これはうっとうしいので、Seam は修飾名を簡単な名前にエイリアスする機能も提供します。 以下のような行を components.xml
ファイルに追加してください。
<factory name="loginAction" scope="STATELESS" value="#{com.jboss.myapp.loginAction}"/>
すべての組み込み Seam コンポーネントは修飾名を持っていますが、 Seamの名前空間をインポートする機能によって非修飾名でもアクセスすることができます。Seam JARに含まれる components.xml
ファイルは以下の名前空間を定義します。
<components xmlns="http://jboss.com/products/seam/components"> <import>org.jboss.seam.core</import> <import>org.jboss.seam.cache</import> <import>org.jboss.seam.transaction</import> <import>org.jboss.seam.framework</import> <import>org.jboss.seam.web</import> <import>org.jboss.seam.faces</import> <import>org.jboss.seam.international</import> <import>org.jboss.seam.theme</import> <import>org.jboss.seam.pageflow</import> <import>org.jboss.seam.bpm</import> <import>org.jboss.seam.jms</import> <import>org.jboss.seam.mail</import> <import>org.jboss.seam.security</import> <import>org.jboss.seam.security.management</import> <import>org.jboss.seam.security.permission</import> <import>org.jboss.seam.captcha</import> <import>org.jboss.seam.excel.exporter</import> <!-- ... ---> </components>
修飾された名前を解決するときは、Seamは順にそれぞれの名前空間を調べます。アプリケーション固有の名前空間のためにはアプリケーションのcomponents.xml
ファイルに追加する名前空間を含めます。
@Scope
アノテーションを使用して、コンポーネントのデフォルトスコープ (コンテキスト) をオーバーライドすることができます。 これにより Seam によってインスタンス化される時に、 コンポーネントインスタンスがどんなコンテキストと結合するかを定義ができます。
@Name("user")
@Entity
@Scope(SESSION)
public class User {
...
}
org.jboss.seam.ScopeType
は、可能なスコープの列挙を定義します。
Some Seam component classes can fulfill more than one role in the system. For example, we often have a User
class which is usually used as a session-scoped component representing the current user but is used in user administration screens as a conversation-scoped component. The @Role
annotation lets us define an additional named role for a component, with a different scope—it lets us bind the same component class to different context variables. (Any Seam component instance may be bound to multiple context variables, but this lets us do it at the class level, and take advantage of auto-instantiation.)
@Name("user")
@Entity
@Scope(CONVERSATION)
@Role(name="currentUser", scope=SESSION)
public class User {
...
}
@Roles
アノテーションは、欲しいだけ多くの追加のロールの指定を可能にします。
@Name("user")
@Entity
@Scope(CONVERSATION)
@Roles({@Role(name="currentUser", scope=SESSION),
@Role(name="tempUser", scope=EVENT)})
public class User {
...
}
多くの良いフレームワークのように、 Seam は自分自身が提供している機能を使うことを心掛けています (Eat Your Own Dog Food) 。 組み込みの Seam インタセプタ (後述) と Seamコンポーネントのセットで実装されています。 これは、アプリケーションがランタイムで組み込みのコンポーネントとやり取り行うことを容易にします。 さらに、組み込みのコンポーネントを独自の実装に置き換えることによって Seam の基本機能をカスタマイズすることさえ容易にします。 組み込みのコンポーネントは Seam の名前空間 org.jboss.seam.core
と 同じ名前の Java パッケージにおいて定義されます。
組み込みコンポーネントは、Seam コンポーネントと同様にインジェクトすることも可能ですが、 便利なスタティック instance()
メソッドも提供します。
FacesMessages.instance().add("Welcome back, #{user.name}!");
依存性の注入 (dependency injection) あるいは 制御の逆転 (inversion of control) は今ではもう大多数の Java 開発者によく知られた概念です。 依存性の注入はあるコンポーネントが他のコンポーネントの参照を持つのを可能にします。 それはコンテナによって setter メソッドあるいはインスタンス変数に他のコンポーネントを「インジェクト (注入)」させることで実現します。 これまであったすべての依存性の注入の実装では、 インジェクションはコンポーネントが生成されたときに起こり、 その後、参照はコンポーネントのライフサイクルの間で変化しません。 ステートレスコンポーネントにおいて、これは理にかなっています。 クライアントの観点から、特定のステートレスなコンポーネントのすべてのインスタンスは交換可能です。 一方、Seamはステートフルなコンポーネントの使用に重点を置いています。 従って、典型的な依存性の注入はもはやあまり有用な構造ではありません。 Seam はインジェクションの一般化として、バイジェクション (bijection) の概念を導入しました。 インジェクションと対比すると、バイジェクションは以下のようになります。
コンテキスト依存 (contextual) - バイジェクションはさまざまな異なるコンテキストからステートフルなコンポーネントを組み立てるために使用されます。 (「より広い (wider) 」コンテキストからのコンポーネントは「より狭い (narrow) 」コンテキストからの参照も持つかもしれません。)
双方向性 (bidirectional) - 値はコンテキスト変数から呼ばれるコンポーネントの属性にインジェクトされ、 また、コンポーネント属性からコンテキストにアウトジェクト (outject) され戻されます。 インスタンス変数そのものを設定することで、呼ばれたコンポーネントが簡単にコンテキスト変数の値を操作することを可能にします。
動的 (dynamic) - バイジェクションはコンポーネントが呼ばれるたびに発生します。 なぜなら、コンテキストの値は時間経過で変化し、 Seam コンポーネントがステートフルだからです。
本質的に、インスタンス変数の値をインジェクト、アウトジェクト、両方により指定することで、 バイジェクションはコンテキスト変数をコンポーネントのインスタンス変数にエイリアスを可能にします もちろん、バイジェクションを可能にするためにアノテーションが使用されています。
@In
アノテーションは値がインスタンス変数にインジェクトされることを指定しています。
@Name("loginAction")
@Stateless
public class LoginAction implements Login {
@In User user;
...
}
あるいは、setter メソッドにインジェクトされます。
@Name("loginAction")
@Stateless
public class LoginAction implements Login {
User user;
@In
public void setUser(User user) {
this.user=user;
}
...
}
デフォルトでは、 Seam はプロパティ名あるいはインジェクトされたインスタンス変数名を使用して、 すべてのコンテキストの優先順位検索を行います。 例えば、 @In("currentUser")
を使用することで明示的にコンテキスト変数を指定することもできます。
指定されたコンテキスト変数と関連した既存のコンポーネントインスタンスが存在しないときに、 Seam にコンポーネントのインスタンスの生成を望むならば、 @In(create=true)
を指定する必要があります。 値がオプションで (null でも可能) であれば、@In(required=false)
を指定してください。
いくつかのコンポーネントでは、 それらが使用されるところではどこでも繰り返し @In(create=true)
を指定する必要があるかもしれません。 このような場合、 コンポーネントに @AutoCreate
アノテーションを付けることが可能で、 create=true
を明示的に使用しなくても、 必要なとき常に作成されるようになります。
式の値をインジェクトすることも可能です。
@Name("loginAction")
@Stateless
public class LoginAction implements Login {
@In("#{user.username}") String username;
...
}
Injected values are disinjected (i.e, set to null
) immediately after method completion and outjection.
(コンポーネントライフサイクルとインジェクションについては次章により多くの情報があります。)
@Out
アノテーションは、属性がインスタンス変数からもアウトジェクトされるべきことを指定します。
@Name("loginAction")
@Stateless
public class LoginAction implements Login {
@Out User user;
...
}
あるいは getter メソッドからアウトジェクトされます。
@Name("loginAction")
@Stateless
public class LoginAction implements Login {
User user;
@Out
public User getUser() {
return user;
}
...
}
属性値はインジェクトされることもアウトジェクトされることも可能です。
@Name("loginAction")
@Stateless
public class LoginAction implements Login {
@In @Out User user;
...
}
または、
@Name("loginAction")
@Stateless
public class LoginAction implements Login {
User user;
@In
public void setUser(User user) {
this.user=user;
}
@Out
public User getUser() {
return user;
}
...
}
セッション Bean とエンティティ Bean Seam コンポーネントは通常の EJB 3.0 のライフサイクルのコールバック (@PostConstruct
、@PreDestroy
など) のすべてをサポートしています。 しかも、Seam は JavaBean コンポーネント でのこれらコールバックの使用もサポートしています。 しかし、これらのアノテーションは J2EE 環境では有効とならないため、Seam は @PostConstruct
と @PreDestroy
と等価な 2 つの追加コンポーネントライフサイクルコールバックを定義しています。
@Create
メソッドは Seam がコンポーネントをインスタンス化した後に呼ばれます。 コンポーネントは 1 つの @Create
メソッドのみ定義可能です。
@Destroy
メソッドは Seam コンポーネントがバインドするコンテキストが終了するときに呼ばれます。 コンポーネントは 1 つの @Destroy
メソッドのみ定義可能です。
さらに、ステートフルセッション Bean コンポーネントはパラメータ無しの@Remove
を付けることが必須 です。このメソッドはコンテキストが終了するときに Seam により呼ばれます。
最後に、関連するアノテーションは @Startup
アノテーションです。 それはアプリケーションやセッションスコープコンポーネントで利用可能です。 @Startup
アノテーションは、 コンテキストが開始されたときにクライアントによる初めての参照を待つのではなく、 Seam に即座にコンポーネントをインスタンス化させさせます。 @Startup(depends={....})
を指定することで、 スタートアップコンポーネントのインスタンス化する順序の制御が可能です。
@Install
アノテーションは、 特定のデプロイメントシナリオでは必須で別の場合はそうでないようなコンポーネントの条件付インストレーションを可能にします。 これは以下の場合に便利です。
テストで特定のインフラストラクチャのコンポーネントをモックとしたい。
特定のデプロイメントシナリオでコンポーネント実装を変更したい。
依存性が有効な場合だけに特定のコンポーネントをインストールしたい (フレームワークの作者に便利)。
@Install
は 優先順位 と 依存性 を指定することで動作します。
コンポーネントの優先順位は、 クラスパス中に同じコンポーネント名を持つ複数のクラスがある場合に、 インストールすべきコンポーネントを決定するために Seam が使用する番号です。 Seam はより優先順位が高いコンポーネントを選択します。 あらかじめ決められた優先順位の値があります (昇順)。
BUILT_IN
— Seam に組み込まれた最も優先順位が低いコンポーネントです。
FRAMEWORK
— サードパーティフレームワークによって定義されたコンポーネントは組み込みコンポーネントをオーバーライドすることが可能ですが、アプリケーションコンポーネントによってオーバーライドされます。
APPLICATION
— デフォルト優先順位、 これはほとんどのアプリケーションコンポーネントにおいて適切です。
DEPLOYMENT
— デプロイメント固有のアプリケーションコンポーネント用です。
MOCK
— テストに使用されるモックオブジェクト用です。
JMS キューと対話する messageSender
という名前のコンポーネントがあるとします。
@Name("messageSender")
public class MessageSender {
public void sendMessage() {
//do something with JMS
}
}
ユニットテストでは、 有効なJMS キューがないので、このメソッドをスタブにしてしまいたくなります。 ユニットテストが実行されるときにクラスパスに存在するけれどアプリケーションではデプロイされない mock コンポーネントを作成します。
@Name("messageSender")
@Install(precedence=MOCK)
public class MockMessageSender extends MessageSender {
public void sendMessage() {
//do nothing!
}
}
優先順位
はクラスパスで両方のコンポーネントを発見したとき、 Seam がどちらのバージョンを使用するかを助けます。
クラスパスにある複数のクラスを正確に制御できるならば、 これはすばらしいことです。 しかし、多くの依存性を持つ再利用可能なフレームワークを記述している場合、 多くの Jar 全体にそのフレームワークを分散させたいとは思わないでしょう。 他にどのようなコンポーネントがインストールされているか、クラスパス中にどんなクラスが使用可能であるかに応じて、 インストールすべきコンポーネントを決める方法の方が好まれるはずです。 @Install
アノテーションはこの機能も制御しています。 Seam は多くの組み込みコンポーネントの条件付きインストールを実現するために内部でこのメカニズムを使用します。 しかし、アプリケーションでは恐らく使用する必要がないでしょう。
以下のようなうっとうしいコードを見るのに飽き飽きしていませんか。
private static final Log log = LogFactory.getLog(CreateOrderAction.class);
public Order createOrder(User user, Product product, int quantity) {
if ( log.isDebugEnabled() ) {
log.debug("Creating new order for user: " + user.username() +
" product: " + product.name()
+ " quantity: " + quantity);
}
return new Order(user, product, quantity);
}
簡単なログメッセージのためのコードをどうしてこんなに冗長にすることができるのか想像するのは困難です。 実際のビジネスロジックに関連するコード行よりロギングに関連する方がより多くあります。 Java コミュニティが 10 年の間もっと良いものを考え出せなかったことは本当に驚きです。
Seam はたくさんのコードを簡素化するロギング API を提供します。
@Logger private Log log;
public Order createOrder(User user, Product product, int quantity) {
log.debug("Creating new order for user: #0 product: #1 quantity: #2", user.username(), product.name(), quantity);
return new Order(user, product, quantity);
}
It doesn't matter if you declare the log
variable static or not—it will work either way, except for entity bean components which require the log
variable to be static.
ストリング連結は、debug()
メソッドの 内部 で起こるため、 うっとうしい if ( log.isDebugEnabled() )
による監視は不要であることに留意してください。 Seam はどのコンポーネントに Log
をインジェクトしたかを知っているため、 通常、ログカテゴリを明示的に指定する必要ないことも留意してください。
User
と Product
が、 現在のコンテキストで有効な Seam コンポーネントの場合、それはさらに良くなります。
@Logger private Log log;
public Order createOrder(User user, Product product, int quantity) {
log.debug("Creating new order for user: #{user.username} product: #{product.name} quantity: #0", quantity);
return new Order(user, product, quantity);
}
Seam ロギングは自動的に log4j あるいは JDK logging に出力を送付するかを選択します。 log4j がクラスパスに通っていれば、Seam はそれを使用します。 そうでなければ、Seam は JDK logging を使用します。
アプリケーションが明示的に setAttribute()
を呼び出すとときに、 セッションにバインドした可変オブジェクトの状態変化が複製されるだけなので、 多くのアプリケーションサーバーの機能は驚くほどいい加減な HttpSession
クラスタリングの実装を持っています。 これはフェイルオーバが発生するときにだけに現れるので、 効果的に開発時にテストされることができないバグの原因です。 さらに実際の複製メッセージはセッション属性とバインドしたシリアライズされたオブジェクトグラフ全体を含んでいます。 そして、それは非効率です。
もちろん、EJB ステートフルセッション Bean は自動的にダーティなチェックと可変状態の複製を実行するのが必要であり、 洗練された EJB コンテナは属性レベルの複製などの最適化を行うことが可能です。 あいにく、すべての Seam ユーザーが EJB 3.0 をサポートする恵まれた環境で作業をしているわけではありません。 そこで、セッションと対話スコープの JavaBean とエンティティ Bean コンポーネントのために、 Seam は Web コンテナセッションクラスタリングの上でクラスタセーフな状態管理の特別なレイヤを提供します。
セッションや対話スコープの JavaBean コンポーネントのために、Seam は、 コンポーネントがアプリケーションにより呼び出される要求の毎に、 setAttribute()
を呼ぶことにより自動的に複製を命じます。 もちろん、このストラテジは読み取りばかりするコンポーネントでは不十分です。 この振る舞いは、 org.jboss.seam.core.Mutable
インタフェースを実装するか、 org.jboss.seam.core.AbstractMutable
を拡張するか、 あるいは、コンポーネント中に独自のダーティチェックのロジックを記述するかにより制御可能です。 以下に例を示します。
@Name("account")
public class Account extends AbstractMutable
{
private BigDecimal balance;
public void setBalance(BigDecimal balance)
{
setDirty(this.balance, balance);
this.balance = balance;
}
public BigDecimal getBalance()
{
return balance;
}
...
}
あるいは、同様の効果を得るために @ReadOnly
アノテーションの使用も可能です。
@Name("account")
public class Account
{
private BigDecimal balance;
public void setBalance(BigDecimal balance)
{
this.balance = balance;
}
@ReadOnly
public BigDecimal getBalance()
{
return balance;
}
...
}
セッションや対話スコープのエンティティ Bean コンポーネントの場合、 Seam は (対話スコープの) エンティティが現在の Seam 管理の永続コンテキストに関連付けられていて、複製が不要ではない場合に限り、 要求毎に setAttribute()
を呼ぶことにより自動的に複製の作成を強制します。 このストラテジは必ずしも効率的ではないので、 セッションや対話スコープエンティティ Bean は注意して使用してください。 エンティティ Bean インスタンスを「管理」するために、 ステートフルセッション Bean や JavaBean をいつでも記述することができます。 以下に例を示します。
@Stateful
@Name("account")
public class AccountManager extends AbstractMutable
{
private Account account; // an entity bean
@Unwrap
public Account getAccount()
{
return account;
}
...
}
Seam アプリケーションフレームワークにおいて EntityHome
クラスは Seam コンポーネントを使用することでエンティティ Bean インスタンスを管理する優れたサンプルを提供していることに留意してください。
Seam コンポーネントではないオブジェクトと連携することもしばしばあります。 しかし、やはり @In
を使用して Seam コンポーネントにインジェクトし、 値やメソッドのバインディング式などでそれらを使いたいと思うことがあります。 時には、それを Seam コンテキストのライフサイクルに関連付ける必要さえあります (例えば @Destroy
)。 そこで、Seam コンテキストは Seam コンポーネントではないオブジェクトを含むことが可能で、 Seam は、コンテキストにバインドする非コンポーネントと連携することを容易にする 2、3 の優れた機能を提供します。
ファクトリコンポーネントパターン は、 Seam コンポーネントをコンポーネントではないオブジェクトのインスタンス化する機能として動作させます。 ファクトリメソッド は、 コンテキスト変数が参照されたときに呼び出されますが、 それとバインドした値は持っていません。 @Factory
アノテーションを使用してファクトリメソッドを定義します。 ファクトリメソッドは値をコンテキスト変数とバインドし、 バインドされた値のスコープを決定します。 二種類のファクトリメソッドスタイルがあります。 最初のスタイルは、Seam によりコンテキストにバインドされた値を返します。
@Factory(scope=CONVERSATION)
public List<Customer
> getCustomerList() {
return ... ;
}
二番目のスタイルは、 値をコンテキスト変数そのものにバインドした void
タイプのメソッドです。
@DataModel List<Customer
> customerList;
@Factory("customerList")
public void initCustomerList() {
customerList = ... ;
}
どちらの場合も、 customerList
コンテキスト変数を参照してその値が null になり、 その値のライフサイクルで行うことがこれ以上ない場合、 ファクトリメソッドが呼ばれます。 さらに強力なパターンは 管理コンポーネントパターン です。 この場合、 コンテキスト変数にバインドする Seam コンポーネントがあり、 このコンポーネントがコンテキスト変数の値を管理し、 残りはクライアントで見えない場合です。
管理コンポーネントは @Unwrap
メソッドを持つすべてのコンポーネントです。 このメソッドは、クライアントに見えなくなる値を返し、 毎回 コンテキスト変数が参照されれば呼び出されます。
@Name("customerList")
@Scope(CONVERSATION)
public class CustomerListManager
{
...
@Unwrap
public List<Customer
> getCustomerList() {
return ... ;
}
}
マネージャコンポーネントパターンはコンポーネントのライフサイクルでより制御を必要とする場面でオブジェクトがあるとき特に有用です。 例えば、コンテキスト終了時にクリーンアップを必要とする重量級のオブジェクトがあるとき、オブジェクトを @Unwrap
し、マネージャコンポーネントの @Destroy
メソッドでクリーンアップすることが可能です。
@Name("hens")
@Scope(APPLICATION)
public class HenHouse {
Set<Hen
> hens;
@In(required=false) Hen hen;
@Unwrap
public List<Hen
> getHens() {
if (hens == null) {
// Setup our hens
}
return hens;
}
@Observer({"chickBorn", "chickenBoughtAtMarket"})
public addHen() {
hens.add(hen);
}
@Observer("chickenSoldAtMarket")
public removeHen() {
hens.remove(hen);
}
@Observer("foxGetsIn")
public removeAllHens() {
hens.clear();
}
...
}
ここでは管理コンポーネントが基礎をなすオブジェクトの多くのイベント監視をしています。 コンポーネントはこれらのアクションそのものを管理し、オブジェクトはアクセスごとにアンラップされるために一貫性のあるビューが提供されます。
XMLベースの構成を最小にするという哲学はSeamでは徹底されています。それにもかかわらず、XMLを使ってSeamを構成したいというさまざまな理由が存在します。 Javaコードからデプロイメント固有の情報を切り離したい、 再利用可能なフレームワークを作成可能にしたい、 Seam組み込み機能を構成したい等の理由です。 Seamはコンポーネントを構成する二つのアプローチを提供します。 プロパティファイルまたは web.xml
でのプロパティ設定による構成と、 components.xml
による構成です。
Seam components may be provided with configuration properties either via servlet context parameters, or via a properties file named seam.properties
in the root of the classpath.
The configurable Seam component must expose JavaBeans-style property setter methods for the configurable attributes. If a Seam component named com.jboss.myapp.settings
has a setter method named setLocale()
, we can provide a property named com.jboss.myapp.settings.locale
in the seam.properties
file or as a servlet context parameter, and Seam will set the value of the locale
attribute whenever it instantiates the component.
The same mechanism is used to configure Seam itself. For example, to set the conversation timeout, we provide a value for org.jboss.seam.core.manager.conversationTimeout
in web.xml
or seam.properties
. (There is a built-in Seam component named org.jboss.seam.core.manager
with a setter method named setConversationTimeout()
.)
components.xml
ファイルはプロパティ設定に比べパワフルです。 次を行うことができます。
Configure components that have been installed automatically—including both built-in components, and application components that have been annotated with the @Name
annotation and picked up by Seam's deployment scanner.
Install classes with no @Name
annotation as Seam components—this is most useful for certain kinds of infrastructural components which can be installed multiple times different names (for example Seam-managed persistence contexts).
@Name
アノテーションを持ってはいるものの、コンポーネントをインストールしないことを示す@Install
のためにデフォルトでインストールしないコンポーネントをインストール可能です。
コンポーネントのスコープを上書き (override) できます。
components.xml
ファイルは次の三つの異なる場所に置くことができます。
war
のWEB-INF
ディレクトリ
jar
のMETA-INF
ディレクトリ
@Name
アノテーション付きのクラスを含む任意のjar
通常、Seamコンポーネントはデプロイメントスキャナーがseam.properties
ファイルやMETA-INF/components.xml
を持つアーカイブ内で @Name
アノテーションの付いたクラスを発見したときにインストールされます (ただし、@Install
アノテーションがデフォルトでインストールしないと 指定していない限り) 。 components.xml
ファイルを使えば、 アノテーションを上書きする必要があるような特別な場合に対処することができます。
例えば、次の components.xml
ファイルはjBPMをインストールします。
<components xmlns="http://jboss.com/products/seam/components"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:bpm="http://jboss.com/products/seam/bpm">
<bpm:jbpm/>
</components
>
これは以下と同じことをします。
<components>
<component class="org.jboss.seam.bpm.Jbpm"/>
</components
>
これは2種類の異なるSeam管理対象永続コンテキストとインストールと構成を行います。
<components xmlns="http://jboss.com/products/seam/components"
xmlns:persistence="http://jboss.com/products/seam/persistence"
<persistence:managed-persistence-context name="customerDatabase"
persistence-unit-jndi-name="java:/customerEntityManagerFactory"/>
<persistence:managed-persistence-context name="accountingDatabase"
persistence-unit-jndi-name="java:/accountingEntityManagerFactory"/>
</components
>
これは以下と同じです。
<components>
<component name="customerDatabase"
class="org.jboss.seam.persistence.ManagedPersistenceContext">
<property name="persistenceUnitJndiName"
>java:/customerEntityManagerFactory</property>
</component>
<component name="accountingDatabase"
class="org.jboss.seam.persistence.ManagedPersistenceContext">
<property name="persistenceUnitJndiName"
>java:/accountingEntityManagerFactory</property>
</component>
</components
>
この例はセッションスコープのSeam管理対象永続コンテキストを生成します (実際には推奨されるものではありません)。
<components xmlns="http://jboss.com/products/seam/components"
xmlns:persistence="http://jboss.com/products/seam/persistence"
<persistence:managed-persistence-context name="productDatabase"
scope="session"
persistence-unit-jndi-name="java:/productEntityManagerFactory"/>
</components
>
<components>
<component name="productDatabase"
scope="session"
class="org.jboss.seam.persistence.ManagedPersistenceContext">
<property name="persistenceUnitJndiName"
>java:/productEntityManagerFactory</property>
</component>
</components
>
永続コンテキストのような基盤となるオブジェクトに対してauto-create
オプションを使用するのは一般的なことです。そうすることで、@In
アノテーションを使うときに明示的にcreate=true
を指定することを防ぐ ことができます。
<components xmlns="http://jboss.com/products/seam/components"
xmlns:persistence="http://jboss.com/products/seam/persistence"
<persistence:managed-persistence-context name="productDatabase"
auto-create="true"
persistence-unit-jndi-name="java:/productEntityManagerFactory"/>
</components
>
<components>
<component name="productDatabase"
auto-create="true"
class="org.jboss.seam.persistence.ManagedPersistenceContext">
<property name="persistenceUnitJndiName"
>java:/productEntityManagerFactory</property>
</component>
</components
>
<factory>
宣言は、値もしくはメソッドバインディング式を指定して、 それが最初に参照されたときにコンテキスト変数値を初期化するようにできます。
<components>
<factory name="contact" method="#{contactManager.loadContact}" scope="CONVERSATION"/>
</components
>
Seamコンポーネントの「エイリアス」 (別名) が生成可能です。
<components>
<factory name="user" value="#{actor}" scope="STATELESS"/>
</components
>
よく使用される式に対しても「エイリアス」を生成することすら可能です。
<components>
<factory name="contact" value="#{contactManager.contact}" scope="STATELESS"/>
</components
>
<factory>
宣言でauto-create="true"
を使うことは 日常的によく目にすることです。
<components>
<factory name="session" value="#{entityManager.delegate}" scope="STATELESS" auto-create="true"/>
</components
>
デプロイとテストの両方において components.xml
ファイルをほんの少し修正するだけで同じファイルを再利用したいということがあります。 Seamは components.xml
ファイル内に@wildcard@
形式のワイルドカードを配置することが可能で、Antビルドスクリプト (デプロイ時) やクラスパスに components.properties
というファイルを与えること (開発時) によって値を置き換えることができます。このアプローチはSeamサンプルプログラムで見ることができます。
もしもXMLで構成が必要な大量のコンポーネントがあるなら、components.xml
に含まれる情報を多くの細かなファイルに分割することは意味があるでしょう。 Seamはあるクラス com.helloworld.Hello
の設定を com/helloworld/Hello.component.xml
という名前のリソース内に置くことができます。 (もしかしたらこのパターンに見覚えがあるかもしれません。なぜなら、 Hibernateでも同様のやり方をしているからです。) そのファイルのルート要素は<components>
または <component>
要素のいずれかが可能です。
最初のオプションはファイル内に複数コンポーネントの定義が可能です。
<components>
<component class="com.helloworld.Hello" name="hello">
<property name="name"
>#{user.name}</property>
</component>
<factory name="message" value="#{hello.message}"/>
</components
>
二番目のオプションは単一コンポーネントしか定義または構成できませんが、 煩雑さはありません。
<component name="hello">
<property name="name"
>#{user.name}</property>
</component
>
二番目のオプションでは、クラス名はコンポーネント定義が登場するファイル名によって暗に指定されます。
あるいは、com/helloworld/components.xml
で com.helloworld
パッケージ内のすべてのクラスの構成をすることも可能です。
文字列、プリミティブ、プリミティブラッパー型は、あなたが予想する通りに構成できます。
org.jboss.seam.core.manager.conversationTimeout 60000
<core:manager conversation-timeout="60000"/>
<component name="org.jboss.seam.core.manager">
<property name="conversationTimeout"
>60000</property>
</component
>
文字列またはプリミティブから構成される配列、セット、リストもサポートされます。
org.jboss.seam.bpm.jbpm.processDefinitions order.jpdl.xml, return.jpdl.xml, inventory.jpdl.xml
<bpm:jbpm>
<bpm:process-definitions>
<value
>order.jpdl.xml</value>
<value
>return.jpdl.xml</value>
<value
>inventory.jpdl.xml</value>
</bpm:process-definitions>
</bpm:jbpm
>
<component name="org.jboss.seam.bpm.jbpm">
<property name="processDefinitions">
<value
>order.jpdl.xml</value>
<value
>return.jpdl.xml</value>
<value
>inventory.jpdl.xml</value>
</property>
</component
>
文字列値のキーと、文字列またはプリミティブの値から成るマップでさえもサポートされます。
<component name="issueEditor">
<property name="issueStatuses">
<key
>open</key
> <value
>open issue</value>
<key
>resolved</key
> <value
>issue resolved by developer</value>
<key
>closed</key
> <value
>resolution accepted by user</value>
</property>
</component
>
When configuring multi-valued properties, by default, Seam will preserve the order in which you place the attributes in components.xml
(unless you use a SortedSet
/SortedMap
then Seam will use TreeMap
/TreeSet
). If the property has a concrete type (for example LinkedList
Seam will use that type.
次のように完全修飾名を指定することでその型を上書きすることも可能です。
<component name="issueEditor">
<property name="issueStatusOptions" type="java.util.LinkedHashMap">
<key
>open</key
> <value
>open issue</value>
<key
>resolved</key
> <value
>issue resolved by developer</value>
<key
>closed</key
> <value
>resolution accepted by user</value>
</property>
</component
>
最後に、値バインディング式 (value-binding expression) を使ってコンポーネントを連携させることができます。 これは@In
を使った注入とはまったく異なるので注意してください。 なぜなら、それは呼び出し時ではなく、コンポーネント生成時に起こるからです。 したがって、JSFやSpringのような既存のIoCコンテナによって提供される依存性注入により近いです。
<drools:managed-working-memory name="policyPricingWorkingMemory"
rule-base="#{policyPricingRules}"/>
<component name="policyPricingWorkingMemory"
class="org.jboss.seam.drools.ManagedWorkingMemory">
<property name="ruleBase"
>#{policyPricingRules}</property>
</component
>
SeamはコンポーネントのBeanプロパティへ初期値を代入する前にEL式の文字列も解決します。そこでコンテキスト依存データをコンポーネントにインジェクトすることも可能になります。
<component name="greeter" class="com.example.action.Greeter">
<property name="message"
>Nice to see you, #{identity.username}!</property>
</component
>
しかし、一つ重要な例外があります。もしも初期値が代入されようとするプロパティの型がSeamのValueExpression
または MethodExpression
であるなら、そのEL式の評価は遅延されます。その代わり、適切な式のラッパーが生成されてそのプロパティに代入されます。SeamアプリケーションフレームワークでのHomeコンポーネントのメッセージテンプレートがその一例になります。
<framework:entity-home name="myEntityHome"
class="com.example.action.MyEntityHome" entity-class="com.example.model.MyEntity"
created-message="'#{myEntityHome.instance.name}' has been successfully added."/>
コンポーネントの内部では、 ValueExpression
または MethodExpression
上で getExpressionString()
を呼び出すことによって式の文字列にアクセス可能です。もしもそのプロパティが ValueExpression
であるなら、その値を getValue()
によって解決可能ですし、もしもそのプロパティがMethodExpression
であるなら、 invoke(Object args...)
を使ってそのメソッドを呼び出すことができます。MethodExpression
プロパティ へ値を代入するためには、その初期値全体は単一のEL式でなければなりません。
例に示す通り、コンポーネントを宣言するには、XML名前空間を使用する、使用しないという二つの相異なる方法があります。以下は名前空間を使用しない典型的なcomponents.xml
ファイルを示します。
<?xml version="1.0" encoding="UTF-8"?>
<components xmlns="http://jboss.com/products/seam/components"
xsi:schemaLocation="http://jboss.com/products/seam/components http://jboss.com/products/seam/components-2.1.xsd">
<component class="org.jboss.seam.core.init">
<property name="debug"
>true</property>
<property name="jndiPattern"
>@jndiPattern@</property>
</component>
</components
>
ご覧の通り、これは幾分煩雑です。 さらに悪いことには、コンポーネントと属性の名前は、デプロイ時の妥当性検証の対象となりません。
名前空間を使ったバージョンはこのようになります。
<?xml version="1.0" encoding="UTF-8"?>
<components xmlns="http://jboss.com/products/seam/components"
xmlns:core="http://jboss.com/products/seam/core"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"http://jboss.com/products/seam/core http://jboss.com/products/seam/core-2.1.xsd
http://jboss.com/products/seam/components http://jboss.com/products/seam/components-2.1.xsd">
<core:init debug="true" jndi-pattern="@jndiPattern@"/>
</components
>
スキーマ宣言は冗長ではありますが、実際のXMLの内容は簡潔かつ理解しやすいものです。 このスキーマは利用可能な各コンポーネントと属性に関する詳細情報を提供するもので、 XMLエディタでインテリジェントな自動補完入力を可能にします。 名前空間付きの要素の使用は、正しいcomponents.xml
ファイルの生成と保守をより簡単にしてくれます。
さて、これは組み込みSeamコンポーネントに対しては良く機能しますが、果たしてユーザーコンポーネントに対してはどうでしょうか。 最初に、Seamは二つの混在したモデルをサポートします。 一つはユーザーコンポーネントに対する一般的な<component>
宣言、 もう一つは組み込みコンポーネントに対する名前空間付きの宣言です。 Seamはユーザーコンポーネントに対しても簡単に名前空間を宣言できるようにしてくれています。
任意のJavaパッケージには、@Namespace
アノテーションをパッケージに付加することによって、XML名前空間を関連付けることができます。 (パッケージレベルのアノテーションは、パッケージディレクトリ内のpackage-info.java
という名前のファイルで宣言されます。) これはseapayデモからの例です。
@Namespace(value="http://jboss.com/products/seam/examples/seampay")
package org.jboss.seam.example.seampay;
import org.jboss.seam.annotations.Namespace;
やらなければならないことは、components.xml
で名前空間スタイルを使うことだけです! こうして次のように書くことが可能になります。
<components xmlns="http://jboss.com/products/seam/components"
xmlns:pay="http://jboss.com/products/seam/examples/seampay"
... >
<pay:payment-home new-instance="#{newPayment}"
created-message="Created a new payment to #{newPayment.payee}" />
<pay:payment name="newPayment"
payee="Somebody"
account="#{selectedAccount}"
payment-date="#{currentDatetime}"
created-date="#{currentDatetime}" />
...
</components
>
または、
<components xmlns="http://jboss.com/products/seam/components"
xmlns:pay="http://jboss.com/products/seam/examples/seampay"
... >
<pay:payment-home>
<pay:new-instance
>"#{newPayment}"</pay:new-instance>
<pay:created-message
>Created a new payment to #{newPayment.payee}</pay:created-message>
</pay:payment-home>
<pay:payment name="newPayment">
<pay:payee
>Somebody"</pay:payee>
<pay:account
>#{selectedAccount}</pay:account>
<pay:payment-date
>#{currentDatetime}</pay:payment-date>
<pay:created-date
>#{currentDatetime}</pay:created-date>
</pay:payment>
...
</components
>
これらのサンプルは名前空間付き要素の二つの利用モデルを説明します。 最初の宣言では<pay:payment-home>
は paymentHome
コンポーネントを参照しています。
package org.jboss.seam.example.seampay;
...
@Name("paymentHome")
public class PaymentController
extends EntityHome<Payment>
{
...
}
その要素名はコンポーネント名をハイフンで連結した形式になっています。 その要素の属性名はプロパティ名をハイフンで連結した形式になっています。
二番目の宣言では、<pay:payment>
要素はorg.jboss.seam.example.seampay
パッケージでのPayment
クラスを参照します。 Payment
のケースでは、あるエンティティがSeamコンポーネントとして宣言されようとしています。
package org.jboss.seam.example.seampay;
...
@Entity
public class Payment
implements Serializable
{
...
}
ユーザー定義コンポーネントに対して妥当性検証と自動補完入力が機能するようにしたいなら、 スキーマが必要になります。Seamはコンポーネントの集まりからスキーマを自動生成するような機能はまだ提供していませんので、手動で生成する必要があります。標準的なSeamパッケージのスキーマ定義はガイドとして利用できます。
次はSeamによって使用済みの名前空間です。
components — http://jboss.com/products/seam/components
core — http://jboss.com/products/seam/core
drools — http://jboss.com/products/seam/drools
framework — http://jboss.com/products/seam/framework
jms — http://jboss.com/products/seam/jms
remoting — http://jboss.com/products/seam/remoting
theme — http://jboss.com/products/seam/theme
security — http://jboss.com/products/seam/security
mail — http://jboss.com/products/seam/mail
web — http://jboss.com/products/seam/web
pdf — http://jboss.com/products/seam/pdf
spring — http://jboss.com/products/seam/spring
コンテキスト依存コンポーネントモデルを補完するものとして、Seamアプリケーションの特徴となっている極度の疎結合を促進させる二つの基本概念が存在します。 最初のものは、イベントがJSFライクなメソッドバインディング式(method binding expression) を通じてイベントリスナーへマップできるような強力なイベントモデルです。 二番目のものは、ビジネスロジックを実装するコンポーネントに対して横断的関心事 (cross-cutting concerns) を適用するためにアノテーションやインタセプタを広範囲に使用しているということです。
Seamコンポーネントモデルはイベント駆動アプリケーション で使うために開発されました。特に、細粒度イベントモデル (fine-grained eventing model) での細粒度かつ疎結合コンポーネント開発を可能にします。 Seamでのイベントは、すでにご存知のように、いくつかのタイプがあります。
JSFイベント
jBPM状態遷移イベント
Seamページアクション
Seamコンポーネント駆動イベント
Seamコンテキスト依存イベント
これらの多様なイベントすべてはJSF ELメソッドバインディング式を通じてSeamコンポーネントへマップされます。JSFイベントは、JSFテンプレートで次のように定義されます。
<h:commandButton value="Click me!" action="#{helloWorld.sayHello}"/>
jBPM遷移イベントは、jBPMプロセス定義またはページフロー定義で規定されます。
<start-page name="hello" view-id="/hello.jsp">
<transition to="hello">
<action expression="#{helloWorld.sayHello}"/>
</transition>
</start-page
>
JSF イベントや jPBM イベントの詳細については本ガイド以外でも見つけることができるので、 ここでは Seam によって定義される別の二種類のイベントについて見ていきます。
Seamページアクションはページのレンダリングの直前に発生するイベントです。 ページアクションはWEB-INF/pages.xml
で宣言します。 特定のJSFビューidのためのページアクションを定義することも可能です。
<pages>
<page view-id="/hello.jsp" action="#{helloWorld.sayHello}"/>
</pages
>
あるいは、 *
ワイルドカードを使ってパターンに一致するすべてのビュー ID
を指定することもできます。
<pages>
<page view-id="/hello/*" action="#{helloWorld.sayHello}"/>
</pages
>
複数のワイルドカード化されたページアクションがカレントビューidに一致するなら、 Seamは曖昧な指定から明確な指定への順 (least-specific to most-specific) で、 それらすべてのアクションを呼び出します。
ページアクションのメソッドはJSF outcomeを返すことができます。もしも、そのoutcome がnullでなければ、Seamはビューをナビゲートするためその定義済みナビゲーション規則を使います。
さらに、<page>
要素で指定されたビューidは、実際のJSPやFacelets に対応する必要はないのです! そこで、ページアクションを使用したStrutsやWebWorkのような 伝統的なアクション指向フレームワークの機能を再現することもできます。
TODO: translate struts action into page action
non-faces要求 (たとえば、 HTTP Get 要求) に対する応答で複雑な処理をしたい場合などに非常に便利です。
複数または条件付きのページアクションは<action>
タグを使って指定できます。
<pages>
<page view-id="/hello.jsp">
<action execute="#{helloWorld.sayHello}" if="#{not validation.failed}"/>
<action execute="#{hitCount.increment}"/>
</page>
</pages
>
JSF faces 要求 (フォーム送信) は「アクション」 (メソッドバインディング) と「パラメータ」 (入力値バインディング) の両方をカプセル化します。 ページアクションにもパラメータが必要かもしれません。
GET 要求はブックマーク可能なので、 ページパラメータは人間が読める要求パラメータとして引き渡されます (JSF フォーム入力とは異なるもの)。
アクションメソッドを指定する、あるいは指定しないページパラメータを使うことができます。
Seamでは、名前付き要求パラメータをモデルオブジェクトの属性を対応させる値バインディングが可能です。
<pages>
<page view-id="/hello.jsp" action="#{helloWorld.sayHello}">
<param name="firstName" value="#{person.firstName}"/>
<param name="lastName" value="#{person.lastName}"/>
</page>
</pages
>
<param>
宣言は双方向で、まさにJSF入力の値バインディングのようです。
指定されたビューidに対するnon-faces (GET) 要求が発生するとき、 Seamは、適切な型変換を施した後に、名前付きパラメータの値をそのモデルオブジェクトに設定します。
任意の <s:link>
や <s:button>
は透過的に要求パラメータを含みます。 パラメータ値は、 レンダリングフェーズの間に (<s:link>
がレンダリングされるとき) 値バインディングを評価することによって決定されます。
ビューidに対する<redirect/>
の任意のナビゲーションルールは要求パラメータを透過的に含みます。パラメータの値はアプリケーションフェーズの最後に値バインディングを評価することで決定されます。
その値は透過的にビューidで指定されたページへのJSFフォーム送信に伝播します。 これはビューパラメータはfaces要求のためのPAGE
スコープのコンテキスト変数のように振舞うことを意味します。
この背後にある本質的な考えは、他の任意のページから /hello.jsp
への (または /hello.jsp
から /hello.jsp
へ戻るような) 遷移があるにもかかわらず、 値バインディングで参照されるモデル属性の値は対話 (または他のサーバ側の状態) を必要とせずに「記録されている」ということです。
もし name
属性が指定されていたら、要求パラメータは PAGE
コンテキストを使って伝播します(モデルプロパティへはマッピングされません)。
<pages>
<page view-id="/hello.jsp" action="#{helloWorld.sayHello}">
<param name="firstName" />
<param name="lastName" />
</page>
</pages
>
ページパラメータの伝播は、マスターから詳細画面に遷移するようなマルチレイヤのCRUDページを作成したいときには特に便利です。それは以前操作していた(例えば、保存ボタンを押したときの)ビューや編集していたビューを「覚えておく」のに使えます。
任意の <s:link>
や <s:button>
は、要求パラメータがビューのページパラメータとして記入されていれば、透過的にそのパラメータを伝播します。
その値は透過的にビューidで指定されたページへのJSFフォーム送信に伝播します。 (これはビューパラメータはfaces要求のためのPAGE
スコープのコンテキスト変数のように振舞います)。
これらすべてはかなり複雑に聞こえますし、そのような変わった概念を努力して使う価値があるのかと疑問に思うことでしょう。実際は、そのアイディアは一旦「理解」してしまえばとても自然なものです。時間をかけてこれを理解することは絶対に価値があります。ページパラメータはnon-faces要求をまたがって状態を伝播するのに最も洗練された方法です。それらは検索結果をブックマーク可能な検索画面にするような問題にとって特に素晴らしい方法です。そのような問題では、同じコードでPOSTとGET要求の両方を処理できるようなアプリケーションコードを書けるようにしたいと望むでしょう。ページパラメータを使えば、ビュー定義内で要求パラメータのリストを繰り返し書く必要がなくなり、リダイレクトをもっと簡単にコーディングできるようになります。
書き換えはpages.xml
内のビューで発見される書き換えパターンを元に発生します。SeamのURL書き換えは同一のパターンに基づいて入力方向と出力方向の両方をURL書き換えを実施します。
<page view-id="/home.xhtml">
<rewrite pattern="/home" />
</page>
この場合は、 /home
のための任意の入力要求は /home.xhtml
に送られます。さらに興味深いことには、通常 /home.seam
を指し示す任意のリンクは /home
に書き換えられます。書き換えパターンはクエリーパラメータの前のURL部分にのみマッチします。それゆえ、 /home.seam?conversationId=13
と /home.seam?color=red
は両方ともこの書き換え規則にマッチします。
書き換え規則は、以下の規則に示すように、これらのクエリーパラメータを考慮することができます。
<page view-id="/home.xhtml">
<rewrite pattern="/home/{color}" />
<rewrite pattern="/home" />
</page>
この場合、 /home/red
の入力要求はあたかも /home.seam?color=red
のように振る舞います。同様に、もしcolor がページパラメータなら /home.seam?color=blue
と通常表示される出力URLは、代わりに /home/blue
と出力されます。
Seamのフィンガープリントを隠す別のオプションを指定することで、デフォルトのSeamクエリーパラメータもURL書き換えを使ってマップ可能です。次の例では、/search.seam?conversationId=13
は/search-13
と書き換えられます。
<page view-id="/search.xhtml">
<rewrite pattern="/search-{conversationId}" />
<rewrite pattern="/search" />
</page>
Seam URL書き換えは、ビュー単位での単純で双方向の書き換えを提供します。非Seamコンポーネントをカバーするより複雑な書き換え規則のためには、Seamアプリケーションは継続して org.tuckey URLRewriteFilter
を使う、あるいはWebサーバでの書き換え規則を適用することが可能です。
URL書き換えはSeamに書き換えフィルタを有効にすることを要求します。書き換えフィルタについては項29.1.4.3. 「URL のリライト」で説明します。
複雑なモデルのプロパティのためにJSFコンバータを指定することも可能です。
<pages>
<page view-id="/calculator.jsp" action="#{calculator.calculate}">
<param name="x" value="#{calculator.lhs}"/>
<param name="y" value="#{calculator.rhs}"/>
<param name="op" converterId="com.my.calculator.OperatorConverter" value="#{calculator.op}"/>
</page>
</pages
>
あるいは代わりに次のようにすることもできます。
<pages>
<page view-id="/calculator.jsp" action="#{calculator.calculate}">
<param name="x" value="#{calculator.lhs}"/>
<param name="y" value="#{calculator.rhs}"/>
<param name="op" converter="#{operatorConverter}" value="#{calculator.op}"/>
</page>
</pages
>
次のように、JSFバリデータと required="true"
も使用できます。
<pages>
<page view-id="/blog.xhtml">
<param name="date"
value="#{blog.date}"
validatorId="com.my.blog.PastDate"
required="true"/>
</page>
</pages
>
あるいは代わりに次のようにすることもできます。
<pages>
<page view-id="/blog.xhtml">
<param name="date"
value="#{blog.date}"
validator="#{pastDateValidator}"
required="true"/>
</page>
</pages
>
さらに良いことには、モデルベースのHiberanteバリデータアノテーションは自動的に認識されて妥当性の検証をします。
型変換や妥当性検証が失敗したなら、グローバルな FacesMessage
がFacesContext
に追加されます。
Seamアプリケーションではfaces-config.xml
で定義される標準のJSFナビゲーション規則を使用できます。しかし、JSFナビゲーション規則は厄介な制限があります。
リダイレクトで使われるときに要求パラメータを指定できません。
規則から対話 (conversation) の開始や終了ができません。
規則はアクションメソッドの戻り値の評価によって動作します。 つまり、任意のEL式を評価することはできません。
さらにpages.xml
と faces-config.xml
の間に「オーケストレーション」ロジックが分散してしまうという問題があります。このロジックは pages.xml
に統合した方が良いでしょう。
このJSFナビゲーション規則は、
<navigation-rule>
<from-view-id
>/editDocument.xhtml</from-view-id>
<navigation-case>
<from-action
>#{documentEditor.update}</from-action>
<from-outcome
>success</from-outcome>
<to-view-id
>/viewDocument.xhtml</to-view-id>
<redirect/>
</navigation-case>
</navigation-rule
>
次のように書き直すことができます。
<page view-id="/editDocument.xhtml">
<navigation from-action="#{documentEditor.update}">
<rule if-outcome="success">
<redirect view-id="/viewDocument.xhtml"/>
</rule>
</navigation>
</page
>
しかし、DocumentEditor
コンポーネントが文字列の戻り値(JSFの結果)を持つような汚いコードを書かなくてすめばさらに良くなるでしょう。Seamでは次のように書くことができます。
<page view-id="/editDocument.xhtml">
<navigation from-action="#{documentEditor.update}"
evaluate="#{documentEditor.errors.size}">
<rule if-outcome="0">
<redirect view-id="/viewDocument.xhtml"/>
</rule>
</navigation>
</page
>
または、次のようにすら書くことができます。
<page view-id="/editDocument.xhtml">
<navigation from-action="#{documentEditor.update}">
<rule if="#{documentEditor.errors.empty}">
<redirect view-id="/viewDocument.xhtml"/>
</rule>
</navigation>
</page
>
最初の形式は後続の規則によって使用されるようにcoutcomeの値を決定する値バインディングを評価します。 二番目のアプローチはoutcomeを無視し、各々の規則の値バインディングを評価します。
もちろん、更新が成功したなら、現在の対話 (conversation) を終了させたいことでしょう。 これには、次のようにします。
<page view-id="/editDocument.xhtml">
<navigation from-action="#{documentEditor.update}">
<rule if="#{documentEditor.errors.empty}">
<end-conversation/>
<redirect view-id="/viewDocument.xhtml"/>
</rule>
</navigation>
</page
>
対話が終了してしまうと、後続の要求は関心があるのがどのドキュメントであるのか知ることができません。要求パラメータとしてドキュメントIDを渡すことができます。そして、それはビューをブックマーク可能にもしてくれます。
<page view-id="/editDocument.xhtml">
<navigation from-action="#{documentEditor.update}">
<rule if="#{documentEditor.errors.empty}">
<end-conversation/>
<redirect view-id="/viewDocument.xhtml">
<param name="documentId" value="#{documentEditor.documentId}"/>
</redirect>
</rule>
</navigation>
</page
>
outcomeがnullとなるのはJSFでは特別なケースです。coucomeがnullは「そのページを再表示する」 という意味に解釈されます。次のナビゲーション規則はnullではないoutcomeに適合しますが、outcomeがnullのものには適合しません。
<page view-id="/editDocument.xhtml">
<navigation from-action="#{documentEditor.update}">
<rule>
<render view-id="/viewDocument.xhtml"/>
</rule>
</navigation>
</page
>
outcomeがnullの場合にナビゲーションをしたいのであれば、 代わりに次の形式を使います。
<page view-id="/editDocument.xhtml">
<navigation from-action="#{documentEditor.update}">
<render view-id="/viewDocument.xhtml"/>
</navigation>
</page
>
ビューidはJSF EL式として与えることができます。
<page view-id="/editDocument.xhtml">
<navigation>
<rule if-outcome="success">
<redirect view-id="/#{userAgent}/displayDocument.xhtml"/>
</rule>
</navigation>
</page
>
もしも、大量のページアクション、ページパラメータ、ナビゲーション規則が あるなら、それらの定義を複数のファイルに分割したいことでしょう。 ビューidが/calc/calculator.jsp
のアクションやパラメータは calc/calculator.page.xml
という名前のリソースに定義可能です。 この場合のルート要素は<page>
要素で、ビューidは暗に指定されます。
<page action="#{calculator.calculate}">
<param name="x" value="#{calculator.lhs}"/>
<param name="y" value="#{calculator.rhs}"/>
<param name="op" converter="#{operatorConverter}" value="#{calculator.op}"/>
</page
>
Seamコンポーネント同士は互いのメソッドを呼ぶことだけでやりとりができます。 ステートフルコンポーネントはobserver/observableパターンを実装することすらできます。 しかし、コンポーネントが互いにメソッドを直接呼ぶとき、より疎結合な方法でやりとりできるために、Seamはコンポーネント駆動イベントを提供します。
イベントリスナー (observers) をcomponents.xml
に指定します。
<components>
<event type="hello">
<action execute="#{helloListener.sayHelloBack}"/>
<action execute="#{logger.logHello}"/>
</event>
</components
>
ここでevent type は単なる任意の文字列です。
イベントが発生するとき、そのイベント用に登録されたアクションはcomponents.xml
に出現した順番で呼び出されます。コンポーネントはどのようにイベントを発行するのでしょうか。Seamはこのために組み込みコンポーネントを提供します。
@Name("helloWorld")
public class HelloWorld {
public void sayHello() {
FacesMessages.instance().add("Hello World!");
Events.instance().raiseEvent("hello");
}
}
あるいは、アノテーションを使うことも可能です。
@Name("helloWorld")
public class HelloWorld {
@RaiseEvent("hello")
public void sayHello() {
FacesMessages.instance().add("Hello World!");
}
}
このイベントプロデューサはイベントコンシューマになんら依存していないことに注意してください。 そのイベントリスナーはまったくプロデューサと依存関係がないように実装できるのです。
@Name("helloListener")
public class HelloListener {
public void sayHelloBack() {
FacesMessages.instance().add("Hello to you too!");
}
}
上記の components.xml
で定義されたメソッドバインディングは、コンシューマへのイベントのマップを扱います。もし components.xml
ファイルを編集するのが嫌ならば、その代わりにアノテーションを使うこともできます。
@Name("helloListener")
public class HelloListener {
@Observer("hello")
public void sayHelloBack() {
FacesMessages.instance().add("Hello to you too!");
}
}
なぜイベントオブジェクトについて今まで何も言及してこなかったのか疑問を思われるかもしれません。Seamでは、イベントプロデューサとリスナーの間の状態の伝播のためのイベントオブジェクトは必要ではありません。状態はSeamコンテキストで保持され、コンポーネント間で共有されます。しかし、もしイベントオブジェクトを渡したいのであれば、次のようにすることも可能です。
@Name("helloWorld")
public class HelloWorld {
private String name;
public void sayHello() {
FacesMessages.instance().add("Hello World, my name is #0.", name);
Events.instance().raiseEvent("hello", name);
}
}
@Name("helloListener")
public class HelloListener {
@Observer("hello")
public void sayHelloBack(String name) {
FacesMessages.instance().add("Hello #0!", name);
}
}
Seamは特殊なフレームワークの統合のためにアプリケーションが利用可能な多くの組み込みイベントを定義します。そのイベントとは次のようなものです。
org.jboss.seam.validationFailed
— JSFバリデーションが失敗したときに呼ばれます
org.jboss.seam.noConversation
— 長期対話が存在しない状態で長期対話が要求されたときに呼ばれます
org.jboss.seam.preSetVariable.<name>
— コンテキスト変数 <name> 設定されたときに呼ばれます
org.jboss.seam.postSetVariable.<name>
— コンテキスト変数 <name> が設定されたときに呼ばれます
org.jboss.seam.preRemoveVariable.<name>
— コンテキスト変数 <name> が設定されなくなったら呼ばれます
org.jboss.seam.postRemoveVariable.<name>
— コンテキスト変数 <name> が設定されなくなったら呼ばれます
org.jboss.seam.preDestroyContext.<SCOPE>
— <SCOPE> コンテキストが破壊される前に呼ばれます
org.jboss.seam.postDestroyContext.<SCOPE>
— <SCOPE> コンテキストが破壊された後に呼ばれます
org.jboss.seam.beginConversation
— called whenever a long-running conversation begins
org.jboss.seam.endConversation
— called whenever a long-running conversation ends
org.jboss.seam.conversationTimeout
— called when a conversation timeout occurs. The conversation id is passed as a parameter.
org.jboss.seam.beginPageflow
— called when a pageflow begins
org.jboss.seam.beginPageflow.<name>
— called when the pageflow <name> begins
org.jboss.seam.endPageflow
— called when a pageflow ends
org.jboss.seam.endPageflow.<name>
— called when the pageflow <name> ends
org.jboss.seam.createProcess.<name>
— called when the process <name> is created
org.jboss.seam.endProcess.<name>
— called when the process <name> ends
org.jboss.seam.initProcess.<name>
— called when the process <name> is associated with the conversation
org.jboss.seam.initTask.<name>
— called when the task <name> is associated with the conversation
org.jboss.seam.startTask.<name>
— called when the task <name> is started
org.jboss.seam.endTask.<name>
— called when the task <name> is ended
org.jboss.seam.postCreate.<name>
— called when the component <name> is created
org.jboss.seam.preDestroy.<name>
— called when the component <name> is destroyed
org.jboss.seam.beforePhase
— called before the start of a JSF phase
org.jboss.seam.afterPhase
— called after the end of a JSF phase
org.jboss.seam.postInitialization
— called when Seam has initialized and started up all components
org.jboss.seam.postReInitialization
— called when Seam has re-initialized and started up all components after a redeploy
org.jboss.seam.postAuthenticate.<name>
— called after a user is authenticated
org.jboss.seam.preAuthenticate.<name>
— called before attempting to authenticate a user
org.jboss.seam.notLoggedIn
— called there is no authenticated user and authentication is required
org.jboss.seam.rememberMe
— occurs when Seam security detects the username in a cookie
org.jboss.seam.exceptionHandled.<type>
— キャッチされなかった例外がSeamによって処理されるときに呼ばれます
org.jboss.seam.exceptionHandled
— キャッチされなかった例外がSeamによって処理されるときに呼ばれます
org.jboss.seam.exceptionNotHandled
— キャッチされなかった例外のためのハンドラが存在しなかったときに呼ばれます
org.jboss.seam.afterTransactionSuccess
— Seamアプリケーションフレームワークでトランザクションが成功するときに呼ばれます
org.jboss.seam.afterTransactionSuccess.<name>
— <name>
という名前のエンティティを管理するSeamアプリケーションフレームワークでトランザクションが成功するときに呼ばれます
Seamコンポーネントは、他のコンポーネント駆動イベントを観察する (observe) のとまったく同様に これらのどのイベントでも観察することが可能です。
EJB 3.0 はセッション Bean コンポーネントに対して標準的なインタセプタモデルを導入しました。 Bean にインタセプタを追加するには、 @AroundInvoke
というアノテーションが付加されたメソッドの付いたクラスを記述して、 その Bean に対してインタセプタのクラス名を指定する @Interceptors
のアノテーションを付ける必要があります。
public class LoggedInInterceptor {
@AroundInvoke
public Object checkLoggedIn(InvocationContext invocation) throws Exception {
boolean isLoggedIn = Contexts.getSessionContext().get("loggedIn")!=null;
if (isLoggedIn) {
//the user is already logged in
return invocation.proceed();
}
else {
//the user is not logged in, fwd to login page
return "login";
}
}
}
このインタセプタをアクションリスナーとして動作するセッションBeanに対して適用するためには、そのセッションBeanに @Interceptors(LoggedInInterceptor.class)
というアノテーションを付加しなければなりません。これはちょっと見栄えの悪いアノテーションです。Seamはクラスレベルインタセプタのためのメタアノテーションとして @Interceptors
を使えるようにEJB3のインタセプタフレームワーク上に構築されています。例えば、以下では、 @LoggedIn
アノテーションを生成します。
@Target(TYPE)
@Retention(RUNTIME)
@Interceptors(LoggedInInterceptor.class)
public @interface LoggedIn {}
こうして、 このインタセプタを適用するのにアクションリスナー Bean に@LoggedIn
アノテーションだけを付加すればよくなりました。
@Stateless
@Name("changePasswordAction")
@LoggedIn
@Interceptors(SeamInterceptor.class)
public class ChangePasswordAction implements ChangePassword {
...
public String changePassword() { ... }
}
インタセプタの順番が重要な場合 (通常は重要となる)、 インタセプタクラスに対して @Interceptor
アノテーションを追加しインタセプタの半順序を指定することが可能です。
@Interceptor(around={BijectionInterceptor.class,
ValidationInterceptor.class,
ConversationInterceptor.class},
within=RemoveInterceptor.class)
public class LoggedInInterceptor
{
...
}
「クライアント側」インタセプタを持つこともできます。 EJB3 のいずれの組み込み機能とでも併用することができます。
@Interceptor(type=CLIENT)
public class LoggedInInterceptor
{
...
}
EJB インタセプタはステートフルで、 インタセプトする対象となるコンポーネントと同じライフルサイクルに従います。 状態を維持する必要がないインタセプタの場合、 Seam では @Interceptor(stateless=true)
を指定することでパフォーマンス最適化ができるようになります。
Seamの多くの機能は、前の例で登場したようなインタセプタを含む組み込みのSeamインタセプタによって実装されています。コンポーネントにアノテーションを付加することによってこれらのインタセプタを明示的に指定する必要はありませんが、インタセプタを適用可能なすべてのSeamコンポーネントのために存在しているのです。
Seam インタセプタは EJB3 Bean だけでなく JavaBean コンポーネントにも使うことができます。
EJB は、 インタセプションを (@AroundInvoke
を使った) ビジネスメソッドだけでなく、 ライフサイクルメソッド @PostConstruct
、 @PreDestroy
、 @PrePassivate
そして @PostActive
に対しても定義します。 Seam は、 コンポーネントとインタセプタに対するこれらすべてのライフサイクルメソッドを EJB3 Bean だけでなく JavaBean コンポーネントに対してもサポートします (JavaBean コンポーネントにとって意味のない @PreDestroy
は除きます)。
JSF は例外処理に関しては驚くほど制限があります。 この問題の部分的な回避策として、 Seam は例外クラスにアノテーションを付けるか XML ファイルに例外クラスを宣言することで例外となる特定クラスを処理する方法を定義することができます。 この機能は、 指定された例外がトランザクションロールバックの原因になるべきか否かを指定するのに EJB 3.0 標準の @ApplicationException
アノテーションと一緒に使われることが意図されていています。
Bean のビジネスメソッドによって例外がスローされると、 その例外は現在のトランザクションに直ちにロールバックが必要として印を付けるかどうかを制御できるよう明確な規則を EJB は定義しています。 システム例外 は常にトランザクションロールバックとなり、 アプリケーション例外 はデフォルトではロールバックとはなりませんが @ApplicationException(rollback=true)
が指定されるとロールバックとなります。 (アプリケーション例外とは、 チェックの付いた例外、 または @ApplicationException
アノテーションが付いたチェックのない例外です。 システム例外とは、 @ApplicationException
アノテーションもチェックも付いていない例外です。)
ロールバック用にトランザクションに印を付けるのと、 実際にロールバックを行うのとは異なります。 例外規則にはトランザクションにロールバックが必要であると印が付けられることだけしか言及していませんが、 例外がスローされた後でもそれはアクティブのままである可能性があるということに注意してください。
Seam は EJB 3.0 例外のロールバック規則を Seam JavaBean コンポーネントに対しても適用します。
しかし、 これらの規則は Seam コンポーネント層でのみ適用されるます。 では、 例外がキャッチされることなく Seam コンポーネント層の外部に伝播し、 さらに JSF 層の外に伝播したらどうなるでしょうか。 仕掛かり中のトランザクションをオープンしたままで放置するのは間違いなので、 例外が発生し Seam コンポーネント層でキャッチされないと Seam はアクティブトランザクションを必ずロールバックします。
Seamの例外処理を有効にするには、主となるサーブレットフィルタをweb.xml
で宣言したことを確認する必要があります。
<filter>
<filter-name
>Seam Filter</filter-name>
<filter-class
>org.jboss.seam.servlet.SeamFilter</filter-class>
</filter>
<filter-mapping>
<filter-name
>Seam Filter</filter-name>
<url-pattern
>*.seam</url-pattern>
</filter-mapping
>
例外ハンドラを機能させる場合は、 web.xml
の Facelets 開発モードおよび components.xml
の Seam デバッグモードも無効にする必要があります。
次の例外は Seam コンポーネント層の外部に伝播すると必ず HTTP 404 エラーになります。 スローされてもすぐには現在のトランザクションをロールバックしませんが、 別の Seam コンポーネントによって例外がキャッチされないとこのトランザクションはロールバックされます。
@HttpError(errorCode=404)
public class ApplicationException extends Exception { ... }
この例外は Seam コンポーネント層の外部に伝播すると必ずブラウザリダイレクトになります。 また、 現在の対話も終了させます。 これにより現在のトランザクションを即時ロールバックさせることになります。
@Redirect(viewId="/failure.xhtml", end=true)
@ApplicationException(rollback=true)
public class UnrecoverableApplicationException extends RuntimeException { ... }
ELを使ってリダイレクト先の ビューid
を指定することも可能です。
この例外は Seam コンポーネント層の外部に伝播すると必ずユーザーへのメッセージを付けてリダイレクトされます。 また、 現在のトランザクションも即時ロールバックさせます。
@Redirect(viewId="/error.xhtml", message="Unexpected error")
public class SystemException extends RuntimeException { ... }
関心のあるすべての例外クラスへアノテーションを付加することは不可能なので、Seamはこの機能を pages.xml
でも指定できるようにしています。
<pages>
<exception class="javax.persistence.EntityNotFoundException">
<http-error error-code="404"/>
</exception>
<exception class="javax.persistence.PersistenceException">
<end-conversation/>
<redirect view-id="/error.xhtml">
<message
>Database access failed</message>
</redirect>
</exception>
<exception>
<end-conversation/>
<redirect view-id="/error.xhtml">
<message
>Unexpected failure</message>
</redirect>
</exception>
</pages
>
最後の <exception>
宣言はクラスを指定していないので、 アノテーションまたは pages.xml
で指定されているもの以外すべての例外をキャッチします。
ELを使ってリダイレクト先の view-id
を指定することもできます。
EL によってキャッチした例外インスタンスにアクセスすることができます。 Seamはそれを対話コンテキストに置きます。例外のメッセージにアクセスする例は次の通り。
...
throw new AuthorizationException("You are not allowed to do this!");
<pages>
<exception class="org.jboss.seam.security.AuthorizationException">
<end-conversation/>
<redirect view-id="/error.xhtml">
<message severity="WARN"
>#{org.jboss.seam.handledException.message}</message>
</redirect>
</exception>
</pages
>
org.jboss.seam.handledException
は例外ハンドラによって実際に処理されたネストされた例外を保持します。その最も外側の(ラッパーの)例外はorg.jboss.seam.caughtException
によって取得可能です。
For the exception handlers defined in pages.xml
, it is possible to declare the logging level at which the exception will be logged, or to even suppress the exception being logged altogether. The attributes log
and logLevel
can be used to control exception logging. By setting log="false"
as per the following example, then no log message will be generated when the specified exception occurs:
<exception class="org.jboss.seam.security.NotLoggedInException" log="false">
<redirect view-id="/register.xhtml">
<message severity="warn"
>You must be a member to use this feature</message>
</redirect>
</exception
>
If the log
attribute is not specified, then it defaults to true
(i.e. the exception will be logged). Alternatively, you can specify the logLevel
to control at which log level the exception will be logged:
<exception class="org.jboss.seam.security.NotLoggedInException" logLevel="info">
<redirect view-id="/register.xhtml">
<message severity="warn"
>You must be a member to use this feature</message>
</redirect>
</exception
>
The acceptable values for logLevel
are: fatal, error, warn, info, debug
or trace
. If the logLevel
is not specified, or if an invalid value is configured, then it will default to error
.
もしJPAを使っている場合
<exception class="javax.persistence.EntityNotFoundException">
<redirect view-id="/error.xhtml">
<message
>Not found</message>
</redirect>
</exception>
<exception class="javax.persistence.OptimisticLockException">
<end-conversation/>
<redirect view-id="/error.xhtml">
<message
>Another user changed the same data, please try again</message>
</redirect>
</exception
>
もしSeamアプリケーションフレームワークを使っている場合
<exception class="org.jboss.seam.framework.EntityNotFoundException">
<redirect view-id="/error.xhtml">
<message
>Not found</message>
</redirect>
</exception
>
もしSeamセキュリティを使っている場合
<exception class="org.jboss.seam.security.AuthorizationException">
<redirect>
<message
>You don't have permission to do this</message>
</redirect>
</exception>
<exception class="org.jboss.seam.security.NotLoggedInException">
<redirect view-id="/login.xhtml">
<message
>Please log in first</message>
</redirect>
</exception
>
そして、JSFの場合
<exception class="javax.faces.application.ViewExpiredException">
<redirect view-id="/error.xhtml">
<message
>Your session has timed out, please try again</message>
</redirect>
</exception
>
ViewExpiredException
はセッションの有効期限が切れたときにポストバックをページに送信しようとすると発生します。もし対話の中で操作中であればno-conversation-view-id
と conversation-required
を使えば細かなセッションの有効期限の制御が可能になります。
本章では、 そろそろ Seam の対話モデルについて詳細に理解していくことにします。
事のはじまりは、 3 つの思いつきが融合した結果、 Seam 「対話」の概念となったことです。
ワークスペース という思いつき、 これは 2002 年にビクトリア州政府 (オーストラリア) のプロジェクトで思いつきました。 このプロジェクトで、私は Struts の上にワークスペース管理を実装せざるを得なくなりました。2 度と繰り返したいとは思わないような経験でした。
楽観的セマンティクスで動作するアプリケーショントランザクションという思いつきに加え、 ステートレスなアーキテクチャをベースとする既存のフレームワークでは拡張された永続コンテキストの効率的な管理は実現できないことを実感した事実でした。 (Hibernate チームは LazyInitializationException
に対する非難は聞き飽きていましたし、 実際にはこれは Hibernate に問題があるのではなく、 むしろ Spring フレームワークや J2EE における従来の stateless session facade (anti) パターンなどステートレスアーキテクチャでサポートされる極端に限定的な永続コンテキストモデルに問題があったのです。)
ワークフロータスクという思いつき
こうした思いつきを統一しフレームワークで強力なサポートを提供することで、 以前よりすっきりしたコードでより豊かで効率的なアプリケーションをビルドできるパワフルな構成概念を得ました。
これまでに見た例は、以下の規則に従う非常に単純な対話モデルを利用します。
JSF 要求ライフサイクルである、 要求値の適用、 プロセスの妥当性検証、 モデル値の更新、 アプリケーションの呼び出し、 応答のレンダリングの各フェーズの期間、 常にアクティブな対話コンテキストがあります。
JSF 要求ライフサイクルであるビューの復元フェーズの終わりで、 Seam はそれまでの長期対話コンテキストの復元を試みます。 存在しなければ、 Seam は新しい一時的な対話コンテキストを生成します。
@Begin
メソッドが出てくると、 一時的な対話コンテキストは長期対話に昇格します。
@End
メソッドが出てくると、 どのような長期対話コンテキストでも一時的な対話に降格されます。
JSF 要求ライフサイクルである応答のレンダリングのフェーズの終わりで、 Seam は長期対話コンテキストの内容を記憶するか、 一時的な対話コンテキストの内容を破棄します。
どのような faces 要求 (JSF ポストバック) でも対話コンテキストを伝播します。 デフォルトでは、 non-faces 要求 (例えば、 GET 要求) は対話コンテキストを伝播しませんが、 これについての詳細は下記を参照してください。
If the JSF request lifecycle is foreshortened by a redirect, Seam transparently stores and restores the current conversation context—unless the conversation was already ended via @End(beforeRedirect=true)
.
Seam は透過的に対話コンテキスト (一時的な対話コンテキストを含む) を JSF ポストパックおよびリダイレクト全体に伝播します。 特に何もしなければ 非 faces 要求 (たとえば GET 要求など) は対話コンテキストを伝播せず新しい一時的な対話内で処理されます。 常にとは限りませんが、 これが通常求められる動作になります。
non-faces 要求全体に Seam 対話を伝播させたい場合、 要求パラメータとして Seam 対話 ID (conversation id) を明示的にコード化する必要があります。
<a href="main.jsf?#{manager.conversationIdParameter}=#{conversation.id}"
>Continue</a
>
JSF のようにする場合には以下のようにします。
<h:outputLink value="main.jsf">
<f:param name="#{manager.conversationIdParameter}" value="#{conversation.id}"/>
<h:outputText value="Continue"/>
</h:outputLink
>
Seam タグライブラリを使用する場合、 以下は等価です。
<h:outputLink value="main.jsf">
<s:conversationId/>
<h:outputText value="Continue"/>
</h:outputLink
>
ポストバック用の対話コンテキストの伝播を無効にしたい場合は、 同様のトリックが使えます。
<h:commandLink action="main" value="Exit">
<f:param name="conversationPropagation" value="none"/>
</h:commandLink
>
Seam タグライブラリを使用する場合、 以下は等価です。
<h:commandLink action="main" value="Exit">
<s:conversationPropagation type="none"/>
</h:commandLink
>
対話コンテキストの伝播を無効にすることと、 対話を終了することとは全く異なることですので注意してください。
conversationPropagation
要求パラメータ または <s:conversationPropagation>
タグは、 対話の開始と終了、あるいはネストされた対話の開始にも使用することができます。
<h:commandLink action="main" value="Exit">
<s:conversationPropagation type="end"/>
</h:commandLink
>
<h:commandLink action="main" value="Select Child">
<s:conversationPropagation type="nested"/>
</h:commandLink
>
<h:commandLink action="main" value="Select Hotel">
<s:conversationPropagation type="begin"/>
</h:commandLink
>
<h:commandLink action="main" value="Select Hotel">
<s:conversationPropagation type="join"/>
</h:commandLink
>
この対話モデルは、 マルチウィンドウ操作に関して正常に動作するアプリケーションの構築を容易してくれます。 多くのアプリケーションにとって必要なものはこれだけです。 複雑なアプリケーションのなかには以下の追加要件の両方あるいはどちらかを必要とするものがあります。
対話には、 連続的に実行したり同時に実行することもある多くの小さな単位のユーザーインタラクションも含まれます。 より小さい ネストされた対話 (nested conversation) には単独の対話状態セットがあり、 また外側の対話状態へのアクセスもあります。
ユーザーは同じブラウザのウィンドウ内でいくつもの対話を切り換えることができます。 この機能がワークスペース管理と呼ばれるものです。
ネストされた対話は既存の対話のスコープ内で @Begin(nested=true)
とマークされたメソッドを呼び出すことによって作成されます。 ネストされた対話はそれ自体の対話コンテキストを持っていますが、 外側の対話のコンテキストから値を読み取ることができます。 オブジェクトは参照により取得されるため外側の対話のコンテキストはネストされた対話内では読み取り専用となりますが、 オブジェクト自体への変更はその外側のコンテキストに反映されます。
対話をネストするとオリジナルの対話または外側の対話のコンテキストに積み重ねられるコンテキストを初期化します。 外側の対話が親とみなされます。
ネストされた対話のコンテキストに直接セットされるまたはアウトジェクトされる値はすべて親となる対話のコンテキスト内にアクセス可能なオブジェクトに影響は与えません。
対話コンテキストからのコンテキスト検索やインジェクションはまず現在の対話コンテキストにある値を検索し、 値がみつかならないと対話がネストされている場合はその対話スタックに進みます。 このあとわかるように、 この動作は上書き可能です。
次に @End
が出てくると、 対話スタックから「ポップ(Pop)」されることで、 その取り出された対話は破棄されます。 対話は任意の深さにネストすることができます。
特定のユーザーアクティビティ (ワークスペース管理や戻るボタン) により、 内側の対話が終了する前に外側の対話が開始させることができます。 この場合、 同じ外側の対話に属する複数の並列ネスト対話を持つことができます。 ネストされた対話が終了する前に外側の対話が終了すると、 Seam はネストされた対話コンテキストを外側のコンテキストと共にすべて破棄します。
対話スタックの最下位にある対話がルートの対話になります。 この対話を破棄すると常に派生した対話はすべて破棄されます。 @End(root=true)
を指定すると宣言的にこれを行うことができます。
対話は継続可能な状態と見なすことができます。 ネストされた対話により、 ユーザーとの交信でのさまざまなポイントにおいてアプリケーションは一貫した継続可能な状態を捕らえることができるようになります。 従って、 戻るボタンを押すことやワークスペース管理に対して正しい動作を保証します。
前述した通り、 現在ネストされている対話の親となる対話にコンポーネントが存在する場合、 このネストされている対話は同じインスタンスを使用します。ときには、 親となる対話内に存在するコンポーネントインスタンスがその子となる対話からは見えなくなるように、 ネストされるそれぞれの対話内に別々のインスタンスを持たせると便利なことがあります。 コンポーネントに @PerNestedConversation
アノテーションを付けるとこれを行うことができます。
ページが non-faces 要求 (例、 HTTP GET 要求) 経由でアクセスされる場合、 JSF は起動されるアクションリスナーを全く定義しません。 ユーザーがそのページをブックマークする、あるいは <h:outputLink>
からそのページに行き着く場合などに発生します。
ページがアクセスされたら直ちに対話を開始したい場合があります。 JSF アクションメソッドがないため、 アクションに @Begin
アノテーションを付けるという普通の方法では問題を解決することができません。
このページが状態をコンテキスト変数にフェッチする必要がある場合、 さらなる問題が発生します。 すでに、2 つの問題解決方法を見てきました。 Seam コンポーネントにその状態が保持される場合、 @Create
メソッドでその状態をフェッチできます。 保持されていなければ、 コンテキスト変数に対して @Factory
メソッドを定義することができます。
これらのオプションがうまくいかない場合、 Seam では pages.xml
ファイルに ページアクション を定義することができます。
<pages>
<page view-id="/messageList.jsp" action="#{messageManager.list}"/>
...
</pages
>
ページがレンダリングされるようとするときは常に、 応答のレンダリングフェーズの冒頭でこのアクションメソッドが呼び出されます。 ページアクションが null 以外の結果を返す場合、 Seam は適切な JSF および Seam ナビゲーションの規則を処理するので、 まったく異なるページがレンダリングさることになるかもしれません。
ページのレンダリング前に行いたいことが対話の開始だけなら、 組み込みアクションメソッドを次のように使用できます。
<pages>
<page view-id="/messageList.jsp" action="#{conversation.begin}"/>
...
</pages
>
また、 この組み込みアクションは JSF コントロールからも呼び出すことができ、 同様に #{conversation.end}
を使って対話を終了することができます。
既存の対話にジョインするあるいはネストされる対話を開始する、 ページフローまたはアトミック対話を開始するためにさらに制御が必要な場合は、 <begin-conversation>
エレメントを使用してください。
<pages>
<page view-id="/messageList.jsp">
<begin-conversation nested="true" pageflow="AddItem"/>
<page>
...
</pages
>
また、 <end-conversation>
エレメントもあります。
<pages>
<page view-id="/home.jsp">
<end-conversation/>
<page>
...
</pages
>
1 番目の問題を解決するには、 現在 5 つのオプションから選択できます。
@Create
メソッドに @Begin
アノテーションを追加する
@Factory
メソッドに @Begin
アノテーションを追加する
Seam ページアクションメソッドに @Begin
アノテーションを追加する
pages.xml
で <begin-conversation>
を使用する
#{conversation.begin}
を Seam ページアクションメソッドとして使用する
JSF コマンドリンクは常に JavaScript でフォームサブミットを行います。 これによりウェブブラウザの「新しいウィンドウで開く」または「新しいタブで開く」機能を動作させなくしてしまいます。 プレーンの JFS でこの機能が必要な場合は、 <h:outputLink>
を使用する必要があります。 ただし、 <h:outputLink>
には重要な制限が 2 つあります。
JSF はアクションリスナーを <h:outputLink>
につなげる方法を提供していません。
実際にフォームサブミットがないため、 JSF は選択された DataModel
の列を伝播しません。
Seam provides the notion of a page action to help solve the first problem, but this does nothing to help us with the second problem. We could work around this by using the RESTful approach of passing a request parameter and requerying for the selected object on the server side. In some cases—such as the Seam blog example application—this is indeed the best approach. The RESTful style supports bookmarking, since it does not require server-side state. In other cases, where we don't care about bookmarks, the use of @DataModel
and @DataModelSelection
is just so convenient and transparent!
この機能を補ってさらに対話伝播の管理をより簡略化するために、 Seam は <s:link>
JSF タグを提供しています。
このリンクは JSF ビュー ID だけを指定することができます。
<s:link view="/login.xhtml" value="Login"/>
あるいは、 アクションメソッドを指定することができます (この場合、 アクションの結果は最終的なページを確定する)。
<s:link action="#{login.logout}" value="Logout"/>
JSF ビュー ID とアクションメソッドの両方を指定すると、 アクションメソッドが null 以外の結果を返さない限り「ビュー」が使用されます。
<s:link view="/loggedOut.xhtml" action="#{login.logout}" value="Logout"/>
リンクは <h:dataTable>
内で使用する DataModel
の選択列を自動的に伝播します。
<s:link view="/hotel.xhtml" action="#{hotelSearch.selectHotel}" value="#{hotel.name}"/>
既存の対話のスコープを残しておくことができます。
<s:link view="/main.xhtml" propagation="none"/>
対話を開始、 終了、 またはネストすることができます。
<s:link action="#{issueEditor.viewComment}" propagation="nest"/>
リンクが対話を開始すると、 使用されるページプローを指定することもできます。
<s:link action="#{documentEditor.getDocument}" propagation="begin"
pageflow="EditDocument"/>
jBPM タスクリストを使用する場合の taskInstance
属性です。
<s:link action="#{documentApproval.approveOrReject}" taskInstance="#{task}"/>
(上記の例は DVD ストアデモアプリケーションを参照してください。)
最後に、 ボタンとしてレンダリングされる「リンク」が必要な場合は <s:button>
を使用します。
<s:button action="#{login.logout}" value="Logout"/>
動作に対して成功したか失敗したかをユーザーに示すメッセージを表示するのは非常に一般的です。 これには、 JSF FacesMessage
を使うと便利です。 残念ながら、 成功のアクションはブラウザリダイレクトを要することが多く、 JSF はリダイレクト全体に faces のメッセージは伝播しません。 このためプレーン JSF で成功のメッセージを表示するのはかなり困難になります。
組み込みの対話スコープ Seam コンポーネントである facesMessages
がこの問題を解決してくれます。 (Seam リダイレクトフィルタをインストールしておく必要があります。)
@Name("editDocumentAction")
@Stateless
public class EditDocumentBean implements EditDocument {
@In EntityManager em;
@In Document document;
@In FacesMessages facesMessages;
public String update() {
em.merge(document);
facesMessages.add("Document updated");
}
}
facesMessages
に追加されるメッセージはすべてすぐ次のフェースである応答レンダリングフェーズで現在の対話に対して使用されます。 これは Seam がリダイレクト全体に一時的な対話コンテキストを維持するので長期実行の対話がない場合でも機能します。
JSF EL 式を faces メッセージサマリーに含ませることもできます。
facesMessages.add("Document #{document.title} was updated");
たとえば、 通常の方法でメッセージを表示することができます。
<h:messages globalOnly="true"/>
永続オブジェクトを処理する対話を作業する場合は標準のサロゲート対話 ID ではなくそのオブジェクトのナチュラルキーを使用する方が望ましい場合があります。
既存の対話に容易にリダイレクト
ユーザーが同じ操作を 2 回要求する場合は既存の対話にリダイレクトすると便利な場合があります。 例をあげてみます。 「 「ebay で両親へのクリスマスプレゼントを獲得しそのアイテムの支払いプロセスが途中まで進んでいます。 ここでこのアイテムが直接両親に配達されるようにしようと思います。 支払い詳細は入力しましたが両親の明確な住所を思い出すことができません。 住所を検索しようとして誤って同じブラウザウィンドウを使ってしまいました。 もう一度さっきのアイテムの支払いに戻る必要があります。」 」
With a natural conversation its really easy to have the user rejoin the existing conversation, and pick up where they left off - just have them to rejoin the payForItem conversation with the itemId as the conversation id.
ユーザーフレンドリーな URL
個人的には操作可能な階層と (URL を編集しながら操作可能) 意味のある URL (この Wiki に見られるようにランダムな ID での識別を行わない) で構成されているように見えますが、 アプリケーションユーザーにとってはフレンドリーな URL はそれほど重要ではない場合もあるでしょう。
With a natural conversations, when you are building your hotel booking system (or, of course, whatever your app is) you can generate a URL like http://seam-hotels/book.seam?hotel=BestWesternAntwerpen
(of course, whatever parameter hotel
maps to on your domain model must be unique) and with URLRewrite easily transform this to http://seam-hotels/book/BestWesternAntwerpen.
かなり改善されたはずです。
ナチュラル対話は pages.xml
で定義されます。
<conversation name="PlaceBid"
parameter-name="auctionId"
parameter-value="#{auction.auctionId}"/>
上記の定義でまず判るのは対話に名前があることです。 この場合 PlaceBid
になります。 名前は特定の指定対話を固有に識別するため page
定義により参加する指定対話の識別に使用されます。
次の属性 parameter-name
はデフォルトの対話 ID パラメータの代わりにナチュラル対話の ID を含む要求パラメータを定義します。 この例では parameter-name
は auctionId
になります。 つまり、 ページの URL 内に出現する cid=123
のような対話パラメータの代わりに auctionId=765432
を含むようになります。
上記の設定の最後の属性 parameter-value
は対話 ID として使用するナチュラルビジネスキーの値の評価に使用される EL 式を定義します。 この例では対話 ID は現在範囲内の auction
のプライマリーキー値になります。
次に指定対話に参加するページを定義します。 page
定義の conversation
属性を指定してこれを行います。
<page view-id="/bid.xhtml" conversation="PlaceBid" login-required="true">
<navigation from-action="#{bidAction.confirmBid}"
>
<rule if-outcome="success">
<redirect view-id="/auction.xhtml">
<param name="id" value="#{bidAction.bid.auction.auctionId}"/>
</redirect>
</rule
>
</navigation>
</page
>
ナチュラル対話を開始またはリダイレクトする場合、 ナチュラル対話名を指定するいくつかのオプションがあります。 次のページ定義をまず見てみることにします。
<page view-id="/auction.xhtml">
<param name="id" value="#{auctionDetail.selectedAuctionId}"/>
<navigation from-action="#{bidAction.placeBid}">
<redirect view-id="/bid.xhtml"/>
</navigation>
</page
>
auction ビューからアクション #{bidAction.placeBid}
を呼び出していること (これらのサンプルはすべて Seam にある seamBay から取得している)、 前述のようにナチュラル対話 PlaceBid
で設定される /bid.xhtml
にリダイレクトしていることがわかります。 アクションメソッドの宣言は以下のようになります。
@Begin(join = true)
public void placeBid()
名前が付けられた対話が <page/>
エレメントに指定される場合、 その名前の対話へのリダイレクトはアクションメソッドが完全に呼び出された後でナビゲーションルールの一部として発生します。 既存の対話にリダイレクトする場合はアクションメソッドが呼び出される前にリダイレクトが発生する必要があるため問題となってきます。 したがってアクションが呼び出される場合は対話名を指定する必要があります。 s:conversationName
タグを使って行うのがその方法のひとつとなります。
<h:commandButton id="placeBidWithAmount" styleClass="placeBid" action="#{bidAction.placeBid}">
<s:conversationName value="PlaceBid"/>
</h:commandButton
>
もうひとつの方法は s:link
または s:button
のどちらかを使用するときに conversationName
を指定する方法です。
<s:link value="Place Bid" action="#{bidAction.placeBid}" conversationName="PlaceBid"/>
ワークスペース管理は、1 つのウィンドウの中で対話を「切り換える」能力です。 Seam はワークスペース管理を Java コードのレベルで完全に透過的にします。 ワークスペース管理を可能にするために、必要なすべては以下の通りです。
それぞれのビュー ID (JSF または Seam ナビゲーションルールを使用する場合) またはページノード (jPDL ページフロー) に詳細のテキストを入力します。 この詳細テキストはワークスペース切り替えによってユーザーに表示されます。
ページの中に 1 つ以上の標準ワークスペース切り替え JSP または facelets の断片を含ませます。 標準の断片はドロップダウンメニュー、 対話のリスト、 ブレッドクラム (breadcrumbs) を通じてワークスペース管理をサポートします。
JSF または Seam ナビゲーションルールを使用する場合、 Seam は対話の現在の view-id
を復元してその対話に切り替えます。 ワークスペースの記述的なテキストは pages.xml
と呼ばれるファイルで定義され、 Seam はこのファイルが WEB-INF
ディレクトリ内の faces-config.xml
のすぐ次に配置されていることを期待します。
<pages>
<page view-id="/main.xhtml">
<description
>Search hotels: #{hotelBooking.searchString}</description>
</page>
<page view-id="/hotel.xhtml">
<description
>View hotel: #{hotel.name}</description>
</page>
<page view-id="/book.xhtml">
<description
>Book hotel: #{hotel.name}</description>
</page>
<page view-id="/confirm.xhtml">
<description
>Confirm: #{booking.description}</description>
</page>
</pages
>
このファイルが期待する場所になくても Seam アプリケーションは正常に動作を続行します。 動作しない機能はワークスペースの切り替え機能のみです。
jPDL ページフロー定義を使う場合、 Seam は現在の jBPM のプロセス状態を復元することによって対話に切り替えます。 同じ view-id
に現在の <page>
に応じて異なる詳細を持たせることができるためこれはより柔軟なモデルになります。 詳細テキストは <page>
ノードで定義されます。
<pageflow-definition name="shopping">
<start-state name="start">
<transition to="browse"/>
</start-state>
<page name="browse" view-id="/browse.xhtml">
<description
>DVD Search: #{search.searchPattern}</description>
<transition to="browse"/>
<transition name="checkout" to="checkout"/>
</page>
<page name="checkout" view-id="/checkout.xhtml">
<description
>Purchase: $#{cart.total}</description>
<transition to="checkout"/>
<transition name="complete" to="complete"/>
</page>
<page name="complete" view-id="/complete.xhtml">
<end-conversation />
</page>
</pageflow-definition
>
次の断片を JSP または facelets のページに含ませて、 現在の対話またはその他いずれのアプリケーションのページにも切り替えられるドロップダウンメニューを取得します。
<h:selectOneMenu value="#{switcher.conversationIdOrOutcome}">
<f:selectItem itemLabel="Find Issues" itemValue="findIssue"/>
<f:selectItem itemLabel="Create Issue" itemValue="editIssue"/>
<f:selectItems value="#{switcher.selectItems}"/>
</h:selectOneMenu>
<h:commandButton action="#{switcher.select}" value="Switch"/>
この例では、 ユーザーに新しい対話を開始させる 2 つの追加アイテムに加えて、 各対話のためのアイテムを含むメニューがあります。
詳細を持つ対話 (pages.xml
で指定) のみがドロップダウンメニューに含まれます。
対話一覧は対話切り替えに非常によく似ていますが、 表形式で表示される点が異なります。
<h:dataTable value="#{conversationList}" var="entry"
rendered="#{not empty conversationList}">
<h:column>
<f:facet name="header"
>Workspace</f:facet>
<h:commandLink action="#{entry.select}" value="#{entry.description}"/>
<h:outputText value="[current]" rendered="#{entry.current}"/>
</h:column>
<h:column>
<f:facet name="header"
>Activity</f:facet>
<h:outputText value="#{entry.startDatetime}">
<f:convertDateTime type="time" pattern="hh:mm a"/>
</h:outputText>
<h:outputText value=" - "/>
<h:outputText value="#{entry.lastDatetime}">
<f:convertDateTime type="time" pattern="hh:mm a"/>
</h:outputText>
</h:column>
<h:column>
<f:facet name="header"
>Action</f:facet>
<h:commandButton action="#{entry.select}" value="#{msg.Switch}"/>
<h:commandButton action="#{entry.destroy}" value="#{msg.Destroy}"/>
</h:column>
</h:dataTable
>
恐らく、 多くの方が独自のアプリケーションに合うようカスタマイズを希望するだろうと思います。
詳細を持つ対話のみがこの一覧に含まれます。
対話一覧によりユーザーがワークスペースを破壊することができるので留意してください。
重要ではありませんが、 JSF コンポーネントへのバインディングの保持には使用できないという制限が対話型コンポーネントにはあります。 (一般的には、 アプリケーション論理からビューに対する強い依存関係を作ってしまうため、 絶対的に必要でない限り一般的にはこの JSF の機能は使用しないようにした方がよいでしょう。) postback 要求で、 Seam 対話コンテキストが復元される前、 ビューの復元フェーズ中にコンポーネントのバインディングは更新されます。
これを回避するには、 イベントスコープコンポーネントを使ってコンポーネントバインディングを格納し、 それを必要とする対話スコープコンポーネントにインジェクトします。
@Name("grid")
@Scope(ScopeType.EVENT)
public class Grid
{
private HtmlPanelGrid htmlPanelGrid;
// getters and setters
...
}
@Name("gridEditor")
@Scope(ScopeType.CONVERSATION)
public class GridEditor
{
@In(required=false)
private Grid grid;
...
}
また、 対話スコープのコンポーネントを JSF コントロールのバインド先となるイベントスコープのコンポーネントにはインジェクトできません。 これには facesMessages
のようなコンポーネント内での Seam 構築が含まれます。
Alternatively, you can access the JSF component tree through the implicit uiComponent
handle. The following example accesses getRowIndex()
of the UIData
component which backs the data table during iteration, it prints the current row number:
<h:dataTable id="lineItemTable" var="lineItem" value="#{orderHome.lineItems}">
<h:column>
Row: #{uiComponent['lineItemTable'].rowIndex}
</h:column>
...
</h:dataTable
>
JSF UI のコンポーネントはこのマップ内のクライアント識別子で使用可能になります。
Seam コンポーネントへの並列コールに関する全般は 項4.1.10. 「同時並行処理モデル」 でご覧ください。 ここでは並列が発生する最も一般的な状況について説明しています (AJAX 要求から対話的コンポーネントにアクセスする)。 クライアントで発生したイベントの制御に Ajax クライアントライブラリが提供すべきオプションについて説明してから RichFaces で提供されるオプションについて見ていきます。
対話的コンポーネントでは実際の並列アクセスは許可されないので、 Seam は要求を連続的に処理するようそれぞれを待ち行列に入れます。 これにより各要求は決定論的に実行されるようになります。 ただし、 シンプルなキューはあまりよくありません。 まず、 メソッドがなんらかの理由で完了に長時間かかっている場合、 クライアントが要求を生成するたび繰り返してそれを実行するのはよくありません (サービス妨害攻撃の可能性)。 また、 ユーザーに対するステータスのクィックアップデートに AJAX が頻繁に使用されるためアクションを長時間実行し続けるのは実用的ではありません。
したがって、 長時間実行の対話の内側で作業する場合は Seam は一定期間アクションイベントを待ち行列に入れます (並列要求タイムアウト)。 時間通りにイベントを処理できないと一時的な対話を作成してユーザーに状況を知らせるメッセージを出力します。 このため、 AJAX イベントでサーバーを溢れさせないようにすることが非常に重要となります。
components.xml で並列要求のタイムアウトにミリ秒単位で適当なデフォルトを設定することができます。
<core:manager concurrent-request-timeout="500" />
また、 ページごとに並列要求のタイムアウトを微調整することもできます。
<page view-id="/book.xhtml"
conversation-required="true"
login-required="true"
concurrent-request-timeout="2000" />
ここまではユーザーに対して連続的に出現する AJAX 要求について説明してきました。 クライアントはサーバーにイベントが発生したことを伝え、 その結果に応じてページの一部を表示します。 この方法は AJAX が軽量である場合には最適となります (1 コラム内の数字の合計を計算するなど呼び出されるメソッドがシンプルである場合)。 しかし、 計算に 1 分を要するような複雑な計算が必要な場合はどうでしょう。
重量のある計算にはポーリングベースの方法を使用してください。 クライアントがサーバーに AJAX 要求を送信し、 これによりサーバーで非同期にアクションが実行され (クライアントへの応答が即時となる)、 クライアントは次にサーバーに更新をポーリングします。 それぞれのアクションがすべて実行する (いずれもタイムアウトしない) ことが重要となるような長時間実行のアクションがある場合に適した方法となります。
まず、 簡単な「連続」要求を使用するのかどうか、 あるいはポーリングの方法を使用するのかどうかを決める必要があります。
「連続」要求を選択する場合は要求が完了する長さを推測する必要があります。 並列要求のタイムアウトに比べ十分に短い時間で完了するかどうか推測してみます。 不十分な場合はこのページの並列要求のタイムアウトを変更します (前述の通り)。 サーバーを要求で溢れさせないようにするためクライアント側で行列待ちをさせた方がよいでしょう。 イベントが頻繁に発生し (入力フィールドの keypress や onblur など) クライアントの即時更新が優先事項ではない場合はクライアント側で要求の遅延をセットしてください。 要求遅延の作業を行う場合、 イベントがサーバー側でも行列待ちできるようにすることを考慮に入れてください。
最後に、 クライアントライブラリは未完了の重複要求を最新のものを残してすべて停止するオプションを提供することができます。
ポールスタイルのデザインを使用する場合は細かな調整があまり必要ありません。 アクションメソッド @Asynchronous
をマークしてポーリングの間隔を決定するだけです。
int total;
// This method is called when an event occurs on the client
// It takes a really long time to execute
@Asynchronous
public void calculateTotal() {
total = someReallyComplicatedCalculation();
}
// This method is called as the result of the poll
// It's very quick to execute
public int getTotal() {
return total;
}
並列要求を対話的コンポーネントに対して行列待ちに入れるよう十分注意をしてアプリケーションを設定しても、 サーバー側がオーバーロードとなり要求処理にかかる時間が concurrent-request-timeout
を越えるまでに全要求を処理できなくなる危険性があります。 こうした場合、 Seam は pages.xml
で処理が可能な ConcurrentRequestTimeoutException
を送出します。 HTTP 503 エラーの送信をお勧めします。
<exception class="org.jboss.seam.ConcurrentRequestTimeoutException" logLevel="trace">
<http-error error-code="503" />
</exception
>
サーバーは現在、 一時的な過負荷またはメンテナンスのため要求を処理することができません。 しばらく待つと緩和されるであろう一時的な状態であることを指します。
代わりにエラーページにリダイレクトすることができます。
<exception class="org.jboss.seam.ConcurrentRequestTimeoutException" logLevel="trace">
<end-conversation/>
<redirect view-id="/error.xhtml">
<message
>The server is too busy to process your request, please try again later</message>
</redirect>
</exception
>
ICEfaces, RichFaces Ajax and Seam Remoting can all handle HTTP error codes. Seam Remoting will pop up a dialog box showing the HTTP error and ICEfaces will indicate the error in it's connection status component. RichFaces Ajax provides the most complete support for handling HTTP errors by providing a user definable callback. For example, to show the error message to the user:
<script type="text/javascript"> A4J.AJAX.onError = function(req,status,message) { alert("message"); }; </script >
RichFaces Ajax は Seam で使用される最も一般的な AJAX ライブラリであり、 上述したような制御をすべて提供します。
eventsQueue
— provide a queue in which events are placed. All events are queued and requests are sent to the server serially. This is useful if the request can to the server can take some time to execute (e.g. heavy computation, retrieving information from a slow source) as the server isn't flooded.
ignoreDupResponses
— ignore the response produced by the request if a more recent 'similar' request is already in the queue. ignoreDupResponses="true" does not cancel the the processing of the request on the server side — just prevents unnecessary updates on the client side.
このオプションは複数の並列要求が作成されるのを許可するため、 Seam の対話で使用する際は注意が必要です。
requestDelay
— 要求がキューに残っている時間を定義します (ミリ秒単位)。 要求がこの時間を過ぎても処理されないと要求は送信されるか (応答が受信されているかどうかにかかわらず) 破棄 (より新しい同様のイベントがキューにある場合) されます。
このオプションは複数の並列要求が作成されるのを許可するため、 Seam の対話で使用する場合は注意が必要です。 アクションが実行に要する時間よりセットした遅延 (並列要求のタイムアウトと併用) の方が長いことを確認する必要があります。
<a:poll reRender="total" interval="1000" />
— サーバーにポーリングを行い必要に応じてエリアを表示します。
JBoss jBPM はJava SE や EE 環境のためのビジネスプロセス管理エンジンです。 jBPM はビジネスプロセスやユーザーインタラクションを、 待ち状態、デシジョン、タスク、WEBページなどノードの図式として表現を可能にします。 図式は簡単でとても読みやすい jPDL と呼ばれる XML 表現を使用して定義されており、 Eclipse プラグインを利用して編集、グラフィックによる視覚化が可能です。 jPDL は拡張可能な言語でありWEB アプリケーションのページフローを定義することから、典型的なワークフローの管理、SOA 環境におけるサービスのオーケストレーションまで対応します。
Seam アプリケーションは jBPM を2 つの異なる問題に使用します。
複雑なユーザーインタラクションを含むページフローを定義します。 jPDL プロセス定義は対話のためのページフローを定義します。 Seamの対話はシングルユーザーとの相対的に短期な対話のインタラクションであると考えられます。
ビジネスプロセスを包括的に定義します。 ビジネスプロセスは、複数ユーザーの複数の対話の範囲を含むかもしれません。 その状態は jBPM データベースの中で永続的なので長期的であると考えられます。 複数ユーザーのアクティビティの調整は、 シングルユーザーとのインタラクションについて動作を記述するよりずっと複雑な問題です。 そこで、jBPM は複数の並行な実行パスを扱うようなタスク管理のための洗練された機能を提供します。
この二つを混乱させないでください!まったく異なるレベルまたは粒度で動作します。Pageflow, conversation と task すべて、一人のユーザーの一つのインタラクションを指しています。ビジネスプロセスはたくさんのタスクに広がります。さらに二つのjBPMアプリケーションは完全に直行しています。それらを一緒にも利用できますし、個別にも利用できます。まったく使わないということもできます。
Seamを使うためにJPDLのことは知らなくていいです。もしページフローの定義やSeamナビゲーションルールの定義に何の問題もなく、アプリケーションがプロセスドリブンよりかはデータドリブンである場合には、おそらくjBPMは必要ないでしょう。しかし、私たちはユーザー間のインタラクションを、よくまとまったグラフィカルな図で考えることは、より堅牢なアプリケーションを構築しやすくしてくれます。
Seam にはページフローを定義する 2 つの方法があります。
JSFあるいはSeam ナビゲーション規則の利用 - ステートレスなナビゲーションモデル
jPDL の利用 - ステートフルなナビゲーションモデル
簡単なアプリケーションではステートレスなナビゲーションモデルで十分です。 とても複雑なアプリケーションは場所に応じて両方を使用します。 それぞれのモデルはそれぞれの強みも弱みもあります。
ステートレスなモデルは 一組の名前の付いた論理的なイベントの結果 (outcome) から 直接、結果として生じるビューのマッピングを定義します。 ナビゲーション規則は、どのページがイベントのソースであったかということ以外、 アプリケーションによって保持されたどのような状態も全く気にしません。 これは、アクションリスナーメソッドがページフローを決めなければならないことがあることを意味しています。 なぜなら、アクションリスナーメソッドだけがアプリケーションの現在の状態にアクセスできるからです。
これは JSF ナビゲーション規則を使用したページフローの例です。
<navigation-rule>
<from-view-id
>/numberGuess.jsp</from-view-id>
<navigation-case>
<from-outcome
>guess</from-outcome>
<to-view-id
>/numberGuess.jsp</to-view-id>
<redirect/>
</navigation-case>
<navigation-case>
<from-outcome
>win</from-outcome>
<to-view-id
>/win.jsp</to-view-id>
<redirect/>
</navigation-case>
<navigation-case>
<from-outcome
>lose</from-outcome>
<to-view-id
>/lose.jsp</to-view-id>
<redirect/>
</navigation-case>
</navigation-rule
>
これは Seam ナビゲーション規則を使用したページフローの例です。
<page view-id="/numberGuess.jsp">
<navigation>
<rule if-outcome="guess">
<redirect view-id="/numberGuess.jsp"/>
</rule>
<rule if-outcome="win">
<redirect view-id="/win.jsp"/>
</rule>
<rule if-outcome="lose">
<redirect view-id="/lose.jsp"/>
</rule>
</navigation>
</page
>
ナビゲーション規則が冗長過ぎると考えるならば、 アクションリスナーメソッドから直接、ビューIDを返すことが可能です。
public String guess() {
if (guess==randomNumber) return "/win.jsp";
if (++guessCount==maxGuesses) return "/lose.jsp";
return null;
}
これは、リダイレクトの結果であることに留意ください。 リダイレクト中に使用するパラメータを指定することも可能です。
public String search() {
return "/searchResults.jsp?searchPattern=#{searchAction.searchPattern}";
}
ステートフルなモデルは名前の付いた論理的なアプリケーションの状態間で起こる遷移の組み合わせを定義します。 このモデルではjPDL ページフロー定義中に、どのようなユーザーインタラクションのフロー表現も可能であり、 インタラクションのフローを全く知らないアクションリスナーメソッドを書くことも可能です。
これは jPDL を使用したページフロー定義の例です。
<pageflow-definition name="numberGuess">
<start-page name="displayGuess" view-id="/numberGuess.jsp">
<redirect/>
<transition name="guess" to="evaluateGuess">
<action expression="#{numberGuess.guess}" />
</transition>
</start-page>
<decision name="evaluateGuess" expression="#{numberGuess.correctGuess}">
<transition name="true" to="win"/>
<transition name="false" to="evaluateRemainingGuesses"/>
</decision>
<decision name="evaluateRemainingGuesses" expression="#{numberGuess.lastGuess}">
<transition name="true" to="lose"/>
<transition name="false" to="displayGuess"/>
</decision>
<page name="win" view-id="/win.jsp">
<redirect/>
<end-conversation />
</page>
<page name="lose" view-id="/lose.jsp">
<redirect/>
<end-conversation />
</page>
</pageflow-definition
>
ここですぐに気づく 二つのことがあります。
JSF/Seam ナビゲーション規則は、より 簡単です。 (しかし、これは根底となる Java コードがより複雑化であるという事実をあいまいにしています。)
jPDL はJSP や Java コードを見る必要がなく、 即座にユーザーインタラクションの理解ができます。
それに加えてステートフルモデルはもっと 制約的 です。 各論理的な状態 (ページフローの各ステップ) に対して他の状態に遷移可能な制約された組み合わせがあります。 ステートレスモデルはアドホックな モデルです。 それはアプリケーションではなく、 比較的制約のない、ユーザーが次に行きたいところを決めるフリーフォームナビゲーションに適しています。
ステートフル / ステートレスナビゲーションの違いは、 典型的なモーダル / モーダレスインタラクションの考え方ととてもよく似ています。 さて、アプリケーションをモーダルな振る舞いから回避することは、 対話を持つ 1 つの主な理由ですが、 Seam アプリケーションは、 通常、単純な意味でのモーダルではありません。 しかし、Seam アプリケーションは、 特定な対話レベルで、モーダル可能であり、しばしばそうです。 モーダルな振る舞いは、 可能な限り回避すべきものとして知られています。 ユーザーがしたいことの順番を予測することは、とても困難です。 しかし、ステートフルモデルの存在意義があるのは疑う余地はありません。
二つのモデルの最大の違いは、 戻るボタンの振る舞いです。
JSF あるいは Seam ナビゲーション規則が使用される場合、 Seam は、ユーザーに戻る、進む、更新ボタンの自由なナビゲーションを可能にします。 これが発生したとき、 内部的な対話状態の一貫性を保持することは、 アプリケーションの責任です。 Struts や WebWork のような対話モデルをサポートしない WEB アプリケーションフレームワーク、 そして、EJB ステートレスセッションBean や Spring framework のようなステートレスコンポーネントモデルの組み合わせの経験は、 多くの開発者にこれをすることは、ほとんど不可能であることを教えていました。 しかし、Seam のコンテキストでの経験から、 ステートフルセッション Bean に裏付けられた明確な対話モデルがあるところでは、 それは実際とても簡単です。 通常、それは、アクションリスナーメソッドの最初に、 no-conversation-view-id アノテーションと null チェックの使用を組合わせるのと同じ位に簡単です。 私たちは、フリーフォームナビゲーションのサポートは、 ほぼいつも要求されるものと考えています。
この場合、no-conversation-view-id
の宣言は pages.xml
で行います。 対話中のレンダリングされたページからの要求の場合、 それは Seam にリダイレクトを指示し、対話はもはや存在しないことを知らせます。
<page view-id="/checkout.xhtml"
no-conversation-view-id="/main.xhtml"/>
一方ステートフルなモデルでは、戻るボタンは以前の状態への未定義な遷移として解釈されます。ステートフルなモデルでは現在の状態から定義済みな遷移のみを行なえるようになっているため、戻るボタンはデフォルトでは有効になっていません。Seam は戻るボタンの利用を透過的に検知します、そして陳腐化した以前のページからの動作を一切ブロックし、単純に現在のページにリダイレクトします。(faces messageを表示します)。これを機能とみるかステートフルモデルの制約とみるかは視点によります:アプリケーション開発者の視点からは機能とみて、ユーザーからの視点としてはフラストレーションを引き起こすようなものかもしれません。back="enabled"
を指定することによって特定のページでの戻るボタンを有効にすることもできます。
<page name="checkout"
view-id="/checkout.xhtml"
back="enabled">
<redirect/>
<transition to="checkout"/>
<transition name="complete" to="complete"/>
</page
>
これは、checkout
状態 から以前のどの状態 にでも戻るボタンでの遷移が可能です。
もちろん、ページフロー時のレンダリングされたページからの要求の場合に何をするのか、そして、その際にページフローでの対話は存在していないのか、といったことを 定義しなければなりません。この場合、no-conversation-view-id
の宣言は、ページフロー定義で行います:
<page name="checkout"
view-id="/checkout.xhtml"
back="enabled"
no-conversation-view-id="/main.xhtml">
<redirect/>
<transition to="checkout"/>
<transition name="complete" to="complete"/>
</page
>
実際には両ナビゲーションモデルとも使い道がありますが、どんなときにどちらのモデルの方が適切かを理解するために、これから簡単に学んでいきます。
Seam の jBPM 関連のコンポーネントをインストールし、Seam アーカイブ ( seam.properties
ファイルを含むアーカイブ ) の中にページフロー定義の場所を ( 標準の jpdl.xml
拡張を使用して ) 指示する必要があります。 この components.xml に Seam 設定を指定することができます。
<bpm:jbpm />
Seam の jBPM 関連のコンポーネントをインストールしページフロー定義の場所を指示する必要があります。 この components.xml
に Seam 設定を指定することができます。
<bpm:jbpm>
<bpm:pageflow-definitions>
<value
>pageflow.jpdl.xml</value>
</bpm:pageflow-definitions>
</bpm:jbpm
>