Exploring CDI extensions
2012/04/22 コメントを残す
InfoQにJBoss SeamとApache DeltaSpikeの今後という記事が出ました。この記事はSeam.NextのアナウンスであるSeamの今後についての発表 – DeltaSpikeプロジェクト誕生の理由の内容と大きな違いはないと思いますが、Peteへの質問「DeltaSpikeはSeam 4のコアになるのですか？」の回答は一歩踏み込んだ発言をしていて興味深いです。何が興味深いかというとツールやチュートリアル、パフォーマンスといった開発者にとっての開発環境や使い勝手に言及しているからです。DeltaSpikeが開発しているのはCDIの共通コンポーネントです。これはCDIを使ったアプリケーションの移植性を考えると確かに重要ですが、Seamの後継はコンポーネントだけではありません。生産性のさらなる向上を目指した真の統合フレームワークです。この統合フレームワークについてはJBoss/Red Hatからの今後の発表を待ちましょう。
2012/01/29 コメントを残す
Seam Solderの使われ方を調べるためにSeam 3.1のseam-bookingサンプルのソースコードを眺めていたら、resource/messages.propertiesとして画面のタイトルやエラーメッセージがリソースとして切り出されているのに気づきました。そこで、日本語リソースファイルを作ってJBoss AS 7にデプロイしたのが下のイメージです。
日本語リソースの作り方は、最初にseam-booking/src/main/resources/messages.propertiesを任意の名前の一時ファイルにコピーして、次のようにプロパティの値部分を翻訳します。
template_linkHome=ホーム template_linkHotels=ホテル検索 template_linkLogin=ログイン template_linkAccount=アカウント template_linkLogout=ログアウト template_linkReset=リセット
次に、それをnative2asciiで変換してmessages_ja.propertiesを作ります。
$ native2ascii 一時ファイル messages_ja.properties
native2asciiの変換結果のmessages_ja.propertiesは次のような感じになります。
template_linkHome=\u30DB\u30FC\u30E0 template_linkHotels=\u30DB\u30C6\u30EB\u691C\u7D22 template_linkLogin=\u30ED\u30B0\u30A4\u30F3 template_linkAccount=\u30A2\u30AB\u30A6\u30F3\u30C8 template_linkLogout=\u30ED\u30B0\u30A2\u30A6\u30C8 template_linkReset=\u30EA\u30BB\u30C3\u30C8
ここまで準備ができたら、あとはmvn installすれば終わりです。
残念ながら、seam-bookingサンプルでは日本語リソースとして切り出されていたのはHome画面（home.xhml)だけです。ユーザー登録画面、検索画面などの他のページでは、タイトルや説明はxhtmlで書かれたUIページのタグに直接埋め込まれています。でも、UI画面からリソースを使うときにサンプルとしては参考になると思います。
2012/01/28 コメントを残す
Seam 3.1が提供するモジュールのひとつであるSolderを調べましょう。Solderは、CDIのアプリケーションやCDI拡張モジュールの開発で便利に使える、次のようなユーティリティ的機能を提供します。
簡単に言うと、SolderはCDIプログラミングの生産性を向上させてくれるものです。ロギングモジュールやXMLによる設定、例外ハンドリングなど、CDIアプリケーションが使うプログラミング上の共通機能を提供します。
また、SolderはCDIの拡張モジュールを作成するための土台となる共通ライブラリも提供します。例えば、InjectionTargetやAnnotatedTypeのデフォルト上書きするために無名クラスを作成してメソッドをオーバーライドするなど、少々プログラミング上扱いづらい点も散見されました。Solderはこれらのインタフェース実装を簡単にするための抽象クラスを提供してくれます。
このブログではこれからSolderの機能の紹介をしようと思いますが、Solderの提供機能は多いので紹介する内容を重要なものに絞りたいと思います。そこで、まず最初に、Seamのソースコード上でSolderのどの機能がよく使われているか調べます。具体的な方法としては、Seam 3.1のexamplesの中でSolderパッケージをimportしている箇所をgrepして、モジュール別のimportの頻度を調べます。正確には、アノテーションの出現頻度を見る方が正確しかもしれませんが、これでも大体の傾向はつかめるでしょう。
$ grep -r "import org.jboss.solder" seam-3.1.0.Final/examples/ | awk -F":" '{print $2}' | sed 's/import //' | tr -d '\r' | sort | uniq -c | sort -r
13 org.jboss.solder.logging.Logger;
4 org.jboss.solder.servlet.event.Initialized;
4 org.jboss.solder.exception.control.HandlesExceptions;
4 org.jboss.solder.exception.control.Handles;
4 org.jboss.solder.exception.control.CaughtException;
4 org.jboss.solder.core.Veto;
3 org.jboss.solder.servlet.WebApplication;
3 org.jboss.solder.core.ExtensionManaged;
1 org.jboss.solder.resourceLoader.Resource;
1 org.jboss.solder.reflection.Reflections;
1 org.jboss.solder.messages.Message;
1 org.jboss.solder.logging.TypedCategory;
1 org.jboss.solder.logging.MessageLogger;
1 org.jboss.solder.logging.Logger.Level;
1 org.jboss.solder.logging.Log;
1 org.jboss.solder.core.Client;
次は、同様に、Seam 3.1が提供する拡張モジュールのソースコードを調べます（量が多いので1回しか登場しないものは割愛しています）。
grep -r "import org.jboss.solder" seam-3.1.0.Final/source/org/jboss/seam/ | awk -F":" '{print $2}' | sed 's/import //' | tr -d '\r' | sort | uniq -c | sort -r
105 org.jboss.solder.logging.Logger;
24 org.jboss.solder.core.Veto;
17 org.jboss.solder.core.Requires;
11 org.jboss.solder.beanManager.BeanManagerLocator;
10 org.jboss.solder.reflection.Reflections;
9 org.jboss.solder.reflection.annotated.AnnotatedTypeBuilder;
8 org.jboss.solder.reflection.AnnotationInspector;
8 org.jboss.solder.exception.control.ExceptionToCatch;
7 org.jboss.solder.literal.DefaultLiteral;
7 org.jboss.solder.el.Expressions;
5 org.jboss.solder.core.Client;
4 org.jboss.solder.util.service.ServiceLoader;
4 org.jboss.solder.util.Sortable;
4 org.jboss.solder.core.ExtensionManaged;
4 org.jboss.solder.bean.defaultbean.DefaultBean;
3 org.jboss.solder.servlet.event.Initialized;
3 org.jboss.solder.servlet.event.Destroyed;
3 org.jboss.solder.properties.Property;
3 org.jboss.solder.literal.AnyLiteral;
3 org.jboss.solder.exception.control.TraversalMode;
3 org.jboss.solder.exception.control.Precedence;
3 org.jboss.solder.exception.control.HandlesExceptions;
3 org.jboss.solder.exception.control.Handles;
3 org.jboss.solder.exception.control.CaughtException;
3 org.jboss.solder.beanManager.BeanManagerAware;
3 org.jboss.solder.bean.ContextualLifecycle;
2 org.jboss.solder.reflection.annotated.Annotateds;
2 org.jboss.solder.properties.query.PropertyQueries;
2 org.jboss.solder.properties.query.PropertyCriteria;
2 org.jboss.solder.literal.NamedLiteral;
2 org.jboss.solder.literal.ApplicationScopedLiteral;
2 org.jboss.solder.bean.ImmutableInjectionPoint;
2 org.jboss.solder.bean.Beans;
2 org.jboss.solder.bean.BeanBuilder;
これらの結果をみると、両方でのケースでLoggerや例外ハンドリング、@Vetoアノテーションの頻度が高そうです。@Vetoは「CDIプログラミングモデルの改善」で導入されたアノテーションです。次回以降では、これらについて調べていきましょう。
2012/01/17 コメントを残す
待望の Seam 3.1.0.Final がリリースされました。ダウンロードはこちらから。
早速、seam-3.1.0.Final.zip をunzip して、お決まりのexamples/seam-booking をビルドしてみました。JBoss AS 7.1CR1b にデプロイして、http://localhost:8080/seam-booking を開くと次のようなログインページが表示されます。
ログインをして、ホテルの検索と予約をしてみましょう。
さて、Seam 3.1.0がリリースされたので、次回からこのブログでも Solder を使ってみましょうか。
2012/01/16 コメントを残す
2011年11月30日に Seam 3 プロジェクトのリードであるShane Bryzak氏によって公開されたSeamの今後についての発表 (Seam.Next Announcement)の全文を翻訳しました。Bryzak氏の許可を得てこのブログに掲載します。原文が公開されてから、かなり時間が経ってしまいましたが、Seam 3プロジェクトの現在の課題とこれからの方向性、DeltaSpikeプロジェクトが生まれた理由について書かれた重要な文書であるため、ぜひ読んでいただきたいと思います。本文に書かれているように、このアナウンスは第1フェーズという位置づけになります。第2フェーズについてもアナウンスがあり次第、このブログで説明する予定です。
Seamの今後についての発表
Seam.Next 計画の第1フェーズに関する詳細をご報告します。私たちがこの作業に取り組んでいる間、辛抱強くお待ちいただき、 e-メール、 IRC 、 Seam フォーラムでフィードバックを下さったすべての方々に深く感謝します。この計画をまとめるのにご尽力いいただいた、モジュール開発リード、主要なコミュニティメンバー、そして、その他の方々に対して感謝します。それはまさに協調作業と言えるものでした。私たちは議論してきたこのアイディアとゴール、これからの方向性について胸を踊らせております。
その肝心な詳細に入る前に、まず最初にそのような変更をすることに至った動機を説明し、その次に、私たちのゴールの全体像についてお話したいと思います。これを説明するのに最良の出発点は Seam 2 でしょう。
Seam 2
Seam 2 で私たちがやってきた事を振り返ってみると、そのフレームワークの多くの側面において成功してきたと言ってもよいと思います。その成功の最も決定的な要因の一つはその統合にあります。Seam 2 はコアフレーワーク機能（依存性注入、コンテキスト、イベント、など）と、アプリケーション開発が生産的な活動になるようなそのコアフレームワーク上に構築された十分便利な機能を提供してきました。
また、Drools、jBPM、Wicket、Spring などのいくつかのサードパーティ技術との統合も提供しました。その上に、すべてを一緒に結びつける優れたドキュメンテーションも提供し、新しい開発者がスピーディに開発できるようにしました。seam-gen や JBoss Tools といった非常に優れたツールについては言うまでもありません。
全体として見れば、Seam 2 は開発者が現代的な Web アプリケーションを構築するときに直面する問題の多くを
開発解決する、成熟した、バランスの取れたフレームワークであることを証明しています。CDI がやって来た
CDI がすべてを変えました。型の安全性と拡張性に集中してSeam のコアフレームワーク機能の多くを標準化し、それらを Java EE プラットフォームの一部としました。これにより、もはや独自フレームワークというものは必要なくなりました。つまり、任意の Java EE 6 互換コンテナは理解しやすいプログラミングモデルを最初から提供します。コアサービスを提供するために追加ライブラリを補う必要はありません。
これは偉大な一歩でした。あなたのアプリケーションが独自の標準に反して書かれるということは良いことです。それはベンダーロックインを避ける助けになりますし、開発者としてのあなたの知識が移植可能になるということを意味しているからです。それは、あなたにとって拡張機能とツールのエコシステムの成長に参画するための良いポジションを獲得することにもなるのです。
どこでも CDI を
CDI がリリースされてからというもの、私たちの仕事の原則の一つは「どこでも CDI を」というものです。私たちのゴールは、できるだけ多くの箇所で CDI を使えるようにすることによって、開発者の生産性を今まで以上に高めることです。そのために、私たちは他のプロジェクトチームに対して彼らのチーム自身が CDI への統合を直接提供するように働きかけ、支援してきました。私たちは、これこそが CDI エコシステムを強化するものであり、開発者がツールと格闘するのではなく、よりビジネスの問題解決に集中できる環境を提供する主な要因だと信じています。
このことは、もちろん、Drools、jBPM（CDI サポートは対応中）、GWT、 Wicket、などのCDIが利用可能になったテクノロジーに対してサポートを提供するSeam のような統合フレームワークが必要なくなったことを意味しています。さらに、Seam 2 で提供したツール（例えば、sem-gen や JBoss Tools）は、プロプライエタリなコアフレームワークをベースとしているため、これから出される新規のツールは、自然の成り行きとして、CDI によって提供される新しい標準ベースのコンポーネントモデルに焦点を合わせるべきです。これが Forge が、 Java EE アプリケーションの構築に集中する、単独でトップレベルのプロジェクトになった理由です。
Seam 3
前の図を見ると、標準化の結果として Seam を構成する多くの部分がオリジナルのプロジェクトの範囲の外へ移動したことがお分かりになるかと思います。これは Seam に明らかに変化があったことを意味しています。Seam 3 は残った部分を CDI のポータブル拡張機能の集合体として作りなおしたのです。本質的には、私たちがやってきたことは、 Seam 2 の中に存在した最も便利なものの多くを実装するのと同時に、新規機能を追加したことです。しかも、Java EE 開発者がこれらの機能をプロジェクトに jar ファイルを追加するだけでアプリケーションに簡単に追加できるようにモジュラー構造でそれらを実現しました。
この時点で、これは後から分かったことですが、プロジェクトの性質が前のバージョンから劇的に変化したのに、この新しいプロジェクトを Seam 3 と呼ぶという愚かな選択をしてしまったとのだと思います。CDI のための便利な拡張の集合を作るのは間違いなく価値のあるゴールではありますが、Seam 3 自身は Seam 2とは違ってもはや完全に統合されたフレームワークスタックではありません。この変化の直接の結果として、多くの方々はそのドキュメンテーションや新しいユーザー向けの開発ガイドに失望してしまいました。
ユーザーが望むものは?
コミュニティから得たフィードバックには、広い範囲の懸念が含まれていましたが、次のような共通の領域にまとめることができました。
- ドキュメンテーション
- 入門ガイド（Getting Started Experience）
- ツール
- Drools/jBPM サポートの不足
- エンティティフレームワークのような不足機能
- マイグレーションガイドの不足
これらの背後には2つの強いメッセージの存在を感じる取ることもできます。
- 開発者の中には移植性に主に関心がある人たちがいます。アプリケーション実装が特定のコンテナ実装にロックインされることを望まず、異なる環境においてフレームワークを自由に使えるということを重視する人たちです。
- 多数の開発者は単に動作する end-to-end のフレームワークを望んでいます。構成要素を自分で組み合わせたり、統合の仕方について苦労をすることは望みません。異なるプロジェクトからの複数のドキュメントを読まなければならないことを望まず、アプリケーションフレームワークに対する主な要求は生産性、つまり仕事を速く効率的にこなすこと、と考えている人たちです。
ここで問題となるのは、いかにして Seam 2 が提供してきたような完全に統合されたフレームワークスタックの開発へ戻るのか、ということです。そしてそのフレームワークは、ポータブル拡張機能（または、それらの組み合わせ）を提供し、CDI が提供される任意の環境上で実行されるのです。私たちはコミュニティリーダーやモジュール開発リードたちと作業をし続け、これらの懸念に対してチャレンジをするという提案をまとめ上げました。
最初のステップはコミュニティがオーナーとなってポータブル CDI 拡張機能を作るということです。つまり、それは開発者が自分自身のアプリケーション内で利用できるデファクトの機能セットであり、どのコンテナに対してもデプロイできるようなものです。このプロジェクトの一つの主要なゴールは Java EE コミュニティを成長させ、統一させることです。Apache MyFaces CODI チームや CDISource チーム、Java EE コミュニティの主要メンバーなどの他の CDI 機能拡張開発者と力を合わせ、別々のコミュニティの集まりよりも強力なコミュニティを作ろうとしています。
これは、プロジェクトが中立であり続けられることを保証するために企業に属さないので、本物のプロジェクトになるに違いありません。私たちは Apache がこのプロジェクトをホストするするのに非常に良い場所であると見なしています。企業の政治に関係の無い非営利団体で、コミュニティで数々の成功したオープンソースプロジェクトを生み出してきたという確固たる評判があるからです。さて、難しい話は抜きにして、さっそく、 Apache DeltaSpikeプロジェクトの紹介をしましょう。
Apache DeltaSpike
あなたがこれを読むときまでには、Apache DeltaSpike は Apache インキュベーターに提出され、トップレベルの Apache プロジェクトになるためのプロセスを開始していることでしょう。DeltaSpike はポータブル CDI 拡張機能の集まりで、Java EE コミュニティでのコラボレーションによって構築されます。それは、さまざまな Java EE オープンソースベンダーからのコードのコントリビューションによって生まれ、エンタープライズアプリケーションを構築するための数々の本質的な機能を提供します。移植性はこのプロジェクトの主原則で、多くの異なる環境で実行可能なフレームワークを開発する多くの開発者の要求を満たします。
それが最初にリリースされた後には、現在の Seam 開発チーム (フルタイムとボランティアのコントリビューターから構成される）は、 MyFaces CODIチーム、 CDISource チーム、他の Java EE コミュニティメンバーと一緒になって、新規機能の開発、イノベーション、バグ修正、その他の改善といった DeltaSpike の開発を遂行します。DeltaSpikeのリリーススケジュールについて言及するのは私の役割ではありませんが（これはApache DeltaSpike Podling Project Management Committee (PPMC)によって決定されるものです）、私はそれが活発なプロジェクトになるであろうということに 100% の確信があります。それは、価値があるプロジェクトなので、世間の注目を浴び、コントリビューションを得て、多くの進行中のリリースを生み出すことでしょう。
Apache DeltaSpike の最初のリリースは、共通のコア、すなわち、機能拡張のベースとなる機能拡張のセットから構成されます。それは複数の Java EE コンテナにわたって移植性を保証するために広範囲にテストされ、他の機能群を開発するための強固な基盤を提供します。最終的にはこの計画は Apache DeltaSpike が Seam に現在見つけることができる機能の多くを組み込めるようにするものです。
統合フレームワーク
私たちは end-to-end の開発スタックを要求する開発者のニーズについても言及しておきたいと思います。この詳細についてはまだ作業中ではありますが、Seam 2 の精神を引き継ぎつつ、しかもより生産性の高い、完全に統合されたフレームワークを提供するということは私たちの中では高い優先度の作業になりますので、どうかご安心いただきたいと思います。ニーズに沿った完全に統合されたフレームワークを提供するための進行中の良いアイディアがいくつかあります。あなた方は私たち同様にこれから起こることにきっと興奮することでしょう。詳細については、数ヶ月の間に起こることに注意していただきたいと思います。
Seam はどうなるのか?
私たちはSeam にすでに多大な投資をしてきた開発者に対してもケアしていきますので、どうか心配しないでください。私たちは見通し得る将来において、Seam 3 の開発を継続します。実際、近々リリースされる Seam 3.1では数多くの興味ある新規モジュールや改善が含まれています。繰り返しになりますが、私たちは Seam コミュニティに対して、上で述べた新たな取り組みがあなた方すべてにとっての利益となるよう全力を傾けたい思います。これから数ヶ月の間、このビジョンを公開するのに今しばらくご辛抱いただくことをお願いし、引き続きご支援をいただくことに対して感謝いたします。
CDI / DeltaSpike について調べたことを書いてます。
なるほど！ザ・Weld 