2009年12月27日

Weldのセッション復帰時に警告

なんかWeldで警告でるなぁ。

どうやら、セッション復帰時で起きてるみたいだけど……。
詳細調べても、解消は出来なかったのだ。

ServletConversationManager(AbstractConversationManagerのcurrentConversationフィールドに、
ConversationImplを放り込もうとしてるみたいね……。
WeldClassImplのdeclaredFieldsByNameフィールドに対象の値が含まれていないのか……。

う〜ん。いいのかな。とりあえず、最初のページだけ出して再デプロイとかすると出てくる……。
まぁ、確かに対話(Conversation)は開始してなかったし、警告レベルだし、問題はないのかな?
でも、スタックトレースも表示されているし……う〜んう〜ん……。
一応、スタックトレースを張っておいてみる!

2009/12/29追記:スタックトレースの表示行がずれてるモジュール使ってたので修正しました。
続きを読む(StackTrace)
posted by そら at 22:30| Comment(0) | TrackBack(0) | 日記

2009年12月23日

Weldの力

JSFとEJBの管理対象

JSF2.0では、クラスに@javax.faces.bean.ManagedBeanと書くと、そのクラスはJSFさんの管理対象になる。
EJB3.1では、クラスに@Statefulとか@Statelessと書くと、そのクラスはEJBさんの管理対象になる。
って話だったんだけど、Weldさんは、クラスに@Namedって書く。

Weldの特徴

Weldは何をするノカって言うと、基本的に大量のアノテーションの提供とそのProcessorをを提供してるのかな。
それによって、JSF2.0とかEJBをまとめて扱えるのだ。おぉ、なんか便利?
たとえば……、 とにかく、@Namedつけておけば、EL式でも参照できる!
なんかこれだけで、@ManagedBeanの役割が無くなった気がする。
さらに、@Namedついたクラスのフィールドとかに@Injectって書くと、
他のManagedBean、Named、Stateful、Statelessつけたやつを適当に入れてくれる!
むー、@EJBも@ManagedPropertyも要らない予感!

結局Weldって?

たった二つのアノテーションでこの威力。
まだまだいっぱいあるけど、正直使いこなせない気がするわ。
トランザクションとかも、Weld使うと、JTA要らずになりそう。
うーむ、本格的にEJB要らない予感が!!!
まぁ、実際には、JSF2.0とかEJBをさらにまとめて管理してる感じなのかな。
まだEJBにしかない機能もあるみたいだし、JSFのフェーズ概念が無くなる訳じゃないけど
Inject周りは、Weldが便利っぽいね。

Weldの使い方

一応、beans.xmlっていうのをWEB-INFの直下に入れないと有効にならないので注意です。
JavaSE環境でも使えるらしいけどよく知らない。
beans.xmlの中身はこんなかんじ。

<?xml version="1.0" encoding="UTF-8"?>
<beans></beans>
うーむ、簡単だけど、有効にするために大分悩んだ(笑)

まとめ

JavaEE6になって、強力で便利な機能がすごく増えてる。Weldに限らず、JSF2.0とかもね。
正直どれだけ使いこなせるか不安になっちゃう……。
OSGiとかも組み込まれて、GlassFishがAP鯖の標準でそこから他のAP鯖がカスタマイズされて提供されるとか言うウワサもあるけど、
JavaEE6がいろんな組織に承認された以上、基本はマスターしておかないとね!

posted by そら at 12:24| Comment(0) | TrackBack(0) | 日記

EJB3.1の簡単なまとめ

定義

EJB3.1では、クラスに@Statefulとか@Statelessと書くと、そのクラスはEJBさんの管理対象になる。
管理されてるオブジェクトは、管理コンテキスト(管理領域)に置かれる。
JSF2.0とかと同じ感じ。
JSF2.0でやるなら、@Statelessじゃなくて、@Statefulもばんばん使っていきたい。

EJBの良いところ

EJBの良いところは、トランザクション管理が出来るところ!JTAってやつね。
これを有効にするには、鯖の対応と、persistence.xmlでJTA使うってやらないとダメなんだよね。
で、もう一つ!
このStatefulとかのを呼び出す(生成する)のに、呼び出し側のクラス(フィールドとか)で@EJBって指定してあげないといけないんだ。
そうしないと、トランザクション管理が有効にならないのだ。
他の方法で呼び出すとトランザクションが開始されてないって怒られたりするので注意。

……なんか色々制約多いなぁ。
結論:EJBは使いにくい(マテ

posted by そら at 12:01| Comment(1) | TrackBack(0) | 日記

JSF2.0の簡単なまとめ

対象定義

JSF2.0では、クラスに@javax.faces.bean.ManagedBeanと書くと、そのクラスはJSFさんの管理対象になる。
管理されてるオブジェクトは、管理コンテキスト(管理領域)に置かれる。

スコープ定義

ついでに、@ViewScopedとかつけると、それの生存期間が設定できる。
ViewScopedは、同じ画面を見てる間有効ってことね。
画面をリフレッシュする系ではプロパティとかが消えずに残るって感じ。

初期処理定義

@PostConstructをメソッドにつけると、初期処理が設定できるのだ。
画面のプルダウンの選択肢を作ったりとか、ここでやると良いのかな。
ちなみに、@PreDestroyで終了処理ね。一応。

利用

@ManagedBeanがついてると、何がうれしいって、EL式で呼び出せるってところ
#{beanName.propertyName}とか#{beanName.methodName(param)}って感じね。
最初に呼ばれた時点でコンストラクタと@PostConstructが順番に呼ばれるのだ。
ボタンとかの実行時に、値もセットしてくれるし、便利便利。

フェーズ

実際、使ってると、スコープってドコまで有効なの?って思って実際に調べてみた。
JSFはなんかライフサイクルって、リクエストごとに一定のフェーズを自動でまわしてくれる。

1RESTORE_VIEW元画面の復元
2APPLY_REQUEST_VALUES元画面にリクエスト内容を適用(この時点では文字列とかのイメージ)
3PROCESS_VALIDATIONS適用した内容の検証
4UPDATE_MODEL_VALUESモデル更新(ここで文字列とかを変換してObjectにして値が更新されるイメージ)
5INVOKE_APPLICATIONここで処理実行
6RENDER_RESPONSE新しい画面描画
基本的には、5に対応するactionListenerのEL式で呼ばれるメソッドと、6のxhtmlを作れば良いってことね。
で、どうやら、ViewScopedだと、次の画面に行くときのRenderResponseフェーズの直前で、消えるみたい。
当然な気もするけど、なんか最初悩んじゃった。

posted by そら at 11:48| Comment(0) | TrackBack(0) | 日記