2010年02月28日

Tomcat6をJavaEE6もどきにする〜その2〜

Weldの1.0.0.SP1と1.0.1-CR2がダウンロードできなくなって、1.0.1-Finalだけになった。
あとEclipseLinkも2.0.1になってる。
というわけで新しくTomcatで動く組み合わせを確認してみたよ(゜▽、゜

jarの名前+Versionどこから?
jsf-api-2.0.2.jarMojarra 2.0.2
jsf-impl-2.0.2.jarMojarra 2.0.2
javax.inject-1.0.1-Final.jarJSR-299 TCK 1.0 1.0.1-Final(Weldの側から)
cdi-api-1.0.1-Final.jarWeld 1.0.1-Final
weld-api-1.0.1-Final.jarWeld 1.0.1-Final
weld-core-1.0.1-Final.jarWeld 1.0.1-Final
weld-servlet-1.0.1-Final.jarWeld 1.0.1-Final
weld-spi-1.0.1-Final.jarWeld 1.0.1-Final
weld-tomcat-support-1.0.1-Final.jarWeld 1.0.1-Final
javax.persistence_2.0.0.v201002051058.jarEclipseLink 2.0.1
eclipselink-2.0.1.v20100213-r6600.jarEclipseLink 2.0.1
validation-api-1.0.0.GA.jarHibernate Validator 4.0.2.GA
hibernate-validator-4.0.2.GA.jarHibernate Validator 4.0.2.GA
jp.empressia.jsf.scope.view-1.0.1.20.jarEmpressia
jp.empressia.logging-1.0.0.12.jarEmpressia
jstl-api-1.2.jarJSTL(GlassFishのサブプロジェクト)
jstl-impl-1.2.jarJSTL(GlassFishのサブプロジェクト)
javassist-3.11.0.jarJavassist 3.11.0(Weldのため)
google-collect-1.0.jarGoogle Collection 1.0(Weldのため)
dom4j-1.6.1.jarネットから探して(Weldのため)

ログ周りは、Weldのservlet.jarかな。に入ってるので別に持ってくる必要はないのだ。
あとEJBのもぽいぽい!ってことで、GlassFishV3から持ってきてたのも取り除いてみた。
あと、WeldのSP1の時は、servet-intが必要だったけど、今回はservletになってるね。
うーむ、20個まで減った!(゜▽、゜いいことだ
WeldはbeforeShutdownが呼ばれるようになったし本当に良かった……(ρ_;)
でもやっぱりGlassFishが良いデス。

posted by すふぃあ at 14:03| Comment(0) | TrackBack(0) | プログラム

Weld(CDI)が1.0.1-Finalになったので対応

Weld(CDI)が1.0.1-FinalにVersionがあがってたので、
ViewScopedのjp.empressia.jsf.scope.view.jarもバージョンを上げて対応したよ。

それにしてもAPI変わりすぎ(笑)
影響されて、1.0.1.19と1.0.1.20で大分変わっちゃった。

1.0.1.19がWeld 1.0.0.SP1用で
1.0.1.20がWeld 1.0.1-Final用ね。

GlassFishV3は、まだVersionがあがってないみたいだから、1.0.1.19で大丈夫そうね。
posted by すふぃあ at 13:53| Comment(0) | TrackBack(0) | プログラム

2010年02月21日

Tomcat6をJavaEE6もどきにする〜その1〜

いろんなサイトで、「JPAをTomcatで」とか。「JSFをTomcatで」とか。
まぁ、色々あるけど、全部一緒に動かす例って無いんだよね。
整合性保つのが大変なのかな?

jp.empressia.scope.view.jarをテストするために色々放り込んで動く環境を確認したので、
これなら動く!って言うのをメモっておくのだ。
Tomcatは6.0.24ね。

JSF2.0(mojarra)+CDI1.0(Weld)+JPA2.0(EclipseLink)と
BeanValidation1.0(Hibernate Validator 4)を入れるのだ。
あとWeld用ViewScopedもね!
ちなみに、jarのバージョン番号とかはわたしが勝手につけた部分もあるので注意。

jarの名前+Versionどこから?
jsf-api-2.0.2.jarMojarra 2.0.2
jsf-impl-2.0.2.jarMojarra 2.0.2
javax.inject-1.0.1-CR1.jarJSR-299 TCK 1.0 1.0.1-CR1(Weldの側から)
cdi-api-1.0.0.SP1.jarWeld 1.0.0.SP1
weld-api-1.0.0.SP1.jarWeld 1.0.0.SP1
weld-core-1.0.0.SP1.jarWeld 1.0.0.SP1
weld-logger-1.0.0.SP1.jarWeld 1.0.0.SP1
weld-servlet-1.0.0.SP1.jarWeld 1.0.0.SP1
weld-servlet-int-1.0.0.SP1.jarWeld 1.0.0.SP1
weld-spi-1.0.0.SP1.jarWeld 1.0.0.SP1
weld-tomcat-support-1.0.0.SP1.jarWeld 1.0.0.SP1
javax.persistence_2.0.0.v200911271158.jarEclipseLink 2.0.0
eclipselink-2.0.0.v20091127-r5931.jarEclipseLink 2.0.0
validation-api-1.0.0.GA.jarHibernate Validator 4.0.2.GA
hibernate-validator-4.0.2.GA.jarHibernate Validator 4.0.2.GA
log4j-1.2.14.jarHibernate Validator 4.0.2.GA
jp.empressia.jsf.scope.view-1.0.1.18.jarEmpressia
jp.empressia.logging-1.0.0.12.jarEmpressia
jstl-api-1.2.jarJSTL(GlassFishのサブプロジェクト)
jstl-impl-1.2.jarJSTL(GlassFishのサブプロジェクト)
javassist-3.11.0.jarJavassist 3.11.0(Weldのため)
google-collect-1.0.jarGoogle Collection 1.0(Weldのため)
dom4j-1.6.1.jarネットから探して(Weldのため)
javax.ejb-glsasfishv3.jarGlassFishV3の中
weld-osgi-bundle-glassfishv3.jarGlassFishV3の中
slf4j-api-1.5.10.jarSLF4J 1.5.10(Hibernate Validatorと他の調整のため)
slf4j-ext-1.5.10.jarSLF4J 1.5.10(Hibernate Validatorと他の調整のため)
slf4j-log4j12-1.5.10.jarSLF4J 1.5.10(Hibernate Validatorと他の調整のため)
cal10n-api-0.7.2.jarネットから探して(Hibernate Validatorと他の調整のため)

全部で29個……( ̄▽ ̄;;)
Tomcatでこれだけめんどくさいの調整するくらいならGlassFishかなぁ(笑)
それぞれのバージョン上げるのも大変そうだね、これ(゜▽、゜

そうそう、これだけがんばってもEL式でメソッド#{bean.method()}みたいなのは使えませんw
EL式使えるようにするには、Tomcat改造しないと無理っぽいから……。
さすがにそんなことするくらいならGlassFishV3でしょ!

あ!これで安心しないように!
DB使うならそれのjarも必要だからね!あわせてTomcatのlibに投入('-^*/⌒°

で、設定ファイルはねー。
Tomcatのconf/context.xmlでしょ〜。WeldのBeanManagerとDBのDataSourceを設定!
WEB-INF/faces-config.xmlでしょ〜。JSF2.0で設定!1.2にしないに注意だよ!
WEB-INF/beans.xmlでしょ〜。からっぽでもは忘れないようにっ!
META-INF/persistence.xmlでしょ〜。RESOURCE_LOCALでnon-jtaだね!
WEB-INF/web.xmlでしょ〜。FacesServletとかいろいろ!
ふー、設定完了(゜▽、゜起動してみてね!
え?動かない!?(ρ_;)イイモン わたしはこれで動くもん

2010/02/28追記:weld-servlet-1.0.0.SP1.jarは、いらなかった!表の中は抹消線つけておいた!ごめん!
posted by すふぃあ at 20:03| Comment(0) | TrackBack(1) | プログラム

JSFとCDI(Weld)の実現するものはWPFに似ている

JSFとCDI使ってWebアプリをいじっていたら、やっとわかったきがした(゜▽、゜
なにがって、なんていうか、実現する構成の方向性みたいなのが。

JSFはStrutsと違ってコンポーネントベースって言われるフレームワークなのね。
Strutsは、URLへのRequest(引数)に対して対象のAction(関数)を呼んで、画面(戻り値)を返す感じ。
JSFは、URLに対応する画面(オブジェクト)があって、画面のアクション(イベント・メソッド)で、状態を変化させていく。
まぁ、どっちもまともに使ったこと無いけど(笑)

Strutsは関数指向。JSFはオブジェクト指向な感じだね。
関数指向は処理が分散しがちでメンテナンスはちょっと気を抜くと大変なことになる。
オブジェクト指向は、正しく作ればメンテナンス性は高くなるけど、処理を分散しにくい。

そうなると、棲み分け的には、
クライアントのアプリとかは、オブジェクト指向で作って、
最近よく聞く、クラウドっていうのは、関数指向で作ることになるんだろうね。
まぁ、オブジェクト指向は、関数指向を受け入れない訳じゃないから、
ハイブリッドとかもあり得るだろうけど。
まぁ、普通の(?)Webアプリ作るならJSFの方が管理とかはずっと楽って言うこと〜。

そして、クライアントとサーバーをまとめて見下ろすと、なんか別の世界が見えてきた。
「あ、これってWPFと同じMVVMじゃん。」
結局、『.NET』も『Java』も行き着くところに行き着いた。という感じなのかな?

MVVMって言うのは、MVCの派生みたいなの。Model-View-ViewModelって感じのやつ。
難しいことはよくわかんないけど、わたし的解釈は、下(↓)に書いたような感じかな。
「画面(View)と画面に出すもの(ViewModel)の関係は、
View→ViewModelでしかもバインドとして疎結合であるべき。
Modelからの依存は許さない。」
バインドってことはその外側でバインディングを管理している人がいるわけなのをお忘れ無く!

MVVM_001.PNG
フレームワークViewViewModelModel
WPF.xamlファイル.xaml.csファイルその他
JSF+Weld.xhtmlファイル.xhtmlに対応した(Managed)Beanその他

結局、どっちもViewに対してViewModelを割り付けて、
Viewで発生したイベントをViewModelで拾ってModelに流してるのね。

JSFだけだと、Modelを完全に切り離すのがめんどくさそうなので、Weldの力を一緒に使うのが良さそう。
っていうことで、Webアプリを作るならJSF+CDI(Weld)が楽っぽいなー。
特にわたしはクライアントアプリ中心にオブジェクト指向でやってきたし(笑)

posted by すふぃあ at 11:58| Comment(1) | TrackBack(0) | プログラム

2010年02月14日

Weld(CDI)好きのJavaEE6なGlassFish(JSF+CDI+JPA)なアノテーション一覧

よく使う?とわたしが独断で思うやつを勝手に一覧化(゜▽、゜
他にどんなのよく使うのかな〜?(・_・?)ハテ
あと、こっそりEmpressiaライブラリも入ってたりする(゚ー゚)ニヤニヤ
画像版↓
JavaEE6_Annotations_Part_20100214.PNG

製品仕様(依存)アノテーションパッケージ個人的分類期待効果
WeldCDI@Namedjavax.injectInject対象管理Inject管理対象としてマーク。
WeldCDI@Injectjavax.injectInject対象管理Inject先のフィールド、Injectするための特殊処理を挟むメソッドを指定する。
WeldCDI@Qualifierjavax.injectInject対象管理InjectとProducesを結びつけるマッピング。
WeldCDI@Producesjavax.enterprise.injectInject対象管理Inject元のィールド、Inject元を生成するメソッドを指定する。
WeldCDI@Disposesjavax.enterprise.injectInject対象管理破棄される時に呼ばれるのを指定。
WeldCDI@ApplicationScopedjavax.enterprise.contextInjectスコープ管理アプリケーション単位での生成と破棄。
WeldCDI@SessionScopedjavax.enterprise.contextInjectスコープ管理セッション単位での生成と破棄。
WeldCDI@RequestScopedjavax.enterprise.contextInjectスコープ管理リクエスト単位での生成と破棄。
WeldCDI@ConversationScopedjavax.enterprise.contextInjectスコープ管理業務単位での生成と破棄。
WeldCDI@Dependentjavax.enterprise.contextInjectスコープ管理Injectされる元に依存した生成と破棄。
WeldCDI@NormalScopedjavax.enterprise.contextInjectスコープ管理新しいスコープを定義するために使う。
EmpressiaWeld@ViewScopedjp.empressia.jsf.scope.viewInjectスコープ管理JSFの画面単位での生成と破棄。
Common AnnotationsCommon Annotations@PostConstructjavax.annotationInject生成管理Inject生成完了した時に行う処理。
Common AnnotationsCommon Annotations@PreDestroyjavax.annotationInject生成管理Inject破棄する前に行う処理。
EclipseLinkJPA@Entityjavax.persistence永続化管理EntityManagerの管理対象としてマーク。
EclipseLinkJPA@Idjavax.persistence永続化管理主キーを指定する。ID指定された対象のEntityが複合主キーを持っている場合は、ばらしたフィールドを別途用意して、@Idをつける必要がある。
Id関連は@Columnとかで名前を指定した方が良いかも。@JoinColumnとか必要になってくるし。
EclipseLinkJPA@OneToManyjavax.persistence関連数指定1対多の関係のあるフィールドに指定する。主にListのフィールドに指定する。相手側からの依存が基本の場合はmappedBy属性を指定する。
EclipseLinkJPA@ManyToOnejavax.persistence関連数指定多対1
EclipseLinkJPA@OneToOnejavax.persistence関連数指定1対1
EclipseLinkJPA@ManyToManyjavax.persistence関連数指定多対多
EclipseLinkJPA@MapKeyjavax.persistence関連指定主にMapなフィールドに指定する。※詳細は確認してない。
EclipseLinkJPA@Embeddablejavax.persistenceテーブルマッピングフィールドの形で同じテーブルに組み込むための定義側指定。
@PrePersist等は動かない。@MappedSuperclassと@Entityのみで動作する。
EclipseLinkJPA@Embeddedjavax.persistenceテーブルマッピングフィールドの形で同じテーブルに組み込むための指定。
EclipseLinkJPA@MappedSuperclassjavax.persistenceテーブルマッピングこれを定義したクラスをEntityで継承すると継承元も永続化対象になる。
@Embed〜系と違って、@PrePersistを定義しておくと動作する。
EclipseLinkJPA@PrePersistjavax.persistence永続化対象管理Insert前に行う処理を指定。
EclipseLinkJPA@PreUpdatejavax.persistence永続化対象管理Update前に行う処理を指定。
EclipseLinkJPA@Temporaljavax.persistence詳細指定日付系に指定する。
EclipseLinkJPA@OrderByjavax.persistence詳細指定順序指定。
EclipseLinkJPA@Transientjavax.persistence詳細指定永続化対象外マーク。
mojarraJSF@ManagedBeanjavax.faces.bean画面対象管理Weld使う時は使用しない。
mojarraJSF@ManagedPropertyjavax.faces.bean画面対象管理Weld使う時は使用しない。
mojarraJSF@ApplicationScopedjavax.faces.beanスコープ管理Weld使う時は使用しない。
mojarraJSF@SessionScopedjavax.faces.beanスコープ管理Weld使う時は使用しない。
mojarraJSF@RequestScopedjavax.faces.beanスコープ管理Weld使う時は使用しない。
mojarraJSF@ViewScopedjavax.faces.beanスコープ管理Weld使う時は使用しない。
mojarraJSF@CustomScopedjavax.faces.beanスコープ管理Weld使う時は使用しない。
mojarraJSF@NoneScopedjavax.faces.beanスコープ管理Weld使う時は使用しない。
mojarraJSF@FacesConverterjavax.faces.convert画面管理独自クラスをプルダウンとかチェックボックスとかに使う場合の定義に使用する。
mojarraJSF@FacesValidatorjavax.faces.validator画面管理独自の入力のチェックを定義する。フロントエンド用。
posted by すふぃあ at 13:10| Comment(0) | TrackBack(0) | プログラム

2010年01月29日

MySQL5.0系の致命的な問題

MySQLひどいなー。これ、DBとして失格じゃない?
3人以上だともっと楽しいことが出来るかもね!
-- フェーズ1
-- 前提処理
CREATE TABLE SIMPLE_TEST (
ID CHAR(8) NOT NULL,
NAME VARCHAR(64) NOT NULL,
PRIMARY KEY (ID)
)
ENGINE = InnoDB;
INSERT INTO SIMPLE_TEST (ID, NAME) VALUES ('0001', 'オリジナルネーム1');
INSERT INTO SIMPLE_TEST (ID, NAME) VALUES ('0002', 'オリジナルネーム2');

-- フェーズ2
-- Aさん作業
-- Aさんトランザクション開始
SELECT * FROM SIMPLE_TEST;
UPDATE SIMPLE_TEST SET NAME = '名前上書き' WHERE ID = '0001';
-- Bさん
-- Bさんトランザクション開始
SELECT * FROM SIMPLE_TEST;

-- フェーズ3
-- Aさん作業
-- Aさんコミット

-- フェーズ4
-- Bさん作業
SELECT * FROM SIMPLE_TEST;
-- ↑Aさんがコミットした値が見えない。
UPDATE SIMPLE_TEST SET NAME = '名前上書き' WHERE ID = '0001';
-- ↑UPDATE件数が0件で正常に終わる。
SELECT * FROM SIMPLE_TEST;
-- ↑UPDATEされたと思っている値が見えない。
-- Bさんコミット
-- ↑仮にCさんが別作業でコミットしててもBさんがやろうとした更新は何も反映されない。

トランザクション内でSELECTすると、作業コピー作って、それを見るみたいなんだけど、
「UPDATE時に作業コピーではなくてマスターのコミット済み領域を見てUPDATE結果が変わらなそうなら何もしない」とか言う制御してるっぽい。
DBとして失格な気がする(゜▽、゜
posted by すふぃあ at 12:45| Comment(0) | TrackBack(0) | プログラム

2009年12月27日

WeldにViewScopedを追加するライブラリ〜その1〜

JavaEE6がでて、おもしろそうなのでいろいろ実験してたんだけど、
Context and Dependency Injection(CDI)って言うのがおもしろいね。
実装は、Weld。JavaSEでも動くみたいだし!

JSF2.0のmojarraとWeldを使ってて、なんだろ、InjectionはやっぱWeldの方がいい(゜▽、゜
さすがって感じ?(なにがっ
でもでも、JSF2.0にはViewScopedがあるんだけど、
Weldには無いんだよね。
かといって、CDI(Weld)のConversationScopedは、JSF2.0にはない……。
ネット見てたら、やっぱ作るしかないらしい……。

というわけで作った!
ダウンロードページ
下の2個のライブラリをlibの中にでも放り込めばOK
jp.empressia.jsf.scope.view.jar
jp.empressia.logging.jar
あとは管理対象に、SessionScopedとか、ConversationScopedと同じように、ViewScopedを書くだけ〜☆
あ、ViewScopedは、JSFの方じゃなくて、jp.empressia.scope.view.ViewScopedね。
便利になった(゚ー゚)(。_。)(゚-゚)(。_。)ウンウン

まだ微妙におかしいところがあるかな……。基本的な動きは大丈夫っぽいので、そこだけ修正しないとダメかな?φ(。。めもめも
↑2009/12/27 追記:1.0.0.15で対応済み♪

posted by すふぃあ at 14:03| Comment(0) | TrackBack(1) | プログラム

2009年09月13日

WPFのRoutedCommandとCommandBinding

ふつーに、WPFなアプリを作ってて、行き詰まりというか、悩んでたことが、解決した。
解決した内容とかは、他のWebサイトとかにも載ってる内容なのでそっちを参考にするっとφ(。。
気が向いたら概要を図にまとめてもいいかな、と思う。
どちらにしても、そこにたどり着いた道筋は、残しておこう。
結局、いろんなサイト見たけど、失敗ケースをやるまで良くわからなかったから。


例1:アプリでUIイベント処理したい。
☆対応1:
 ・通常のWindowに対してメソッド作成した。
 ・Windowに操作対象Objectを保持した。
 ・Windowの中のButtonからメソッドを呼んだ。
 結果:
  できた。
 問題点:
  ButtonとWindowが切り離せない。
WPFCommandBinding01.png


例2:例1に対してUIイベント処理を非同期化したい。
☆対応1:
 ・メソッドに対してdelegateを宣言、代入した。
 結果:UIに対する結果反映処理が別スレッドからの処理となりエラー。
☆対応2:
 ・BackgroundWorkerを使った。
 結果:
  できた。
 問題点:
  操作対象objectがWindowにあるので、以下のどちらかにする必要がある。
  1.thisアクセスする
  2.イベントのResult等にobjectを入れて引き回す
  1の場合は、非同期処理をするメソッドと、後処理のメソッドは同クラスから切り離せない。


例3:例2に対して、別の場所から操作対象を処理したい。
☆対応1:
 ・別ユーザーコントロールを作った。
 ・ユーザーコントロールに例1と同様にobjectを保持した。
 ・ユーザーコントロールに例2と同様にメソッドを作成した。
 結果:
  できた。
 問題点:
  処理は出来たが、他のUIに処理結果が反映できなかった。


ここで、前から疑問に想っていたICommandとRoutedCommandとCommandBinding言うものが良くわかった。
作りながらも3回くらい、調べては、あきらめを繰り返してきたけど、
これらを(これらも)解決できる仕掛けの提供になっているんだね。
もっと洗練できそうな気もするけど。

ちょうど、想像してた仕掛けの解説っぽい記事を発見したので張っておこうっと。
antsk blog : WPFのCommand
自分の見たかった図とかが載ってた。
これを基準にPreviewExecuteとかExecutedを利用すればよさげ。
うみゅ、満足(゜▽、゜ねむいゾ
posted by すふぃあ at 13:03| Comment(0) | TrackBack(0) | プログラム

2008年08月02日

StateパターンとStrategyパターン

んーと、なんかよくわからないので整理してみる。

状態とかタイプとかで、処理が分岐するときに使うパターン。

・状態の数が固定・可変(後から追加)。
数が固定の場合は、当然Enumで表現できる。
数が可変の場合は、クラスの継承で表現する。

数が固定っていっても、状態の数が変わるかも!とか考え出すとEnum使えないんだよね。
ここで言う追加って言うのは、他の人が追加するってこと。
自分で追加……は、えっと、許されるんだよね?(汗)
Enumの拡張とか継承みたいなのってあり得ないのかなぁ。

話を戻すと……、処理を状態に含めないなら上だけで済むんだけど、
実際には、処理も放り込みたいんだよね。
というわけでさらに以下の場合によって実装ってかわるっとφ(。。

・状態別の処理が固定・可変(?)。

数が固定で、状態別の処理が固定なら、当然Enumに放り込むよね。
数が可変で、状態別の処理が固定なら、状態別のクラスに実装すればOK。

数が可変で状態別の処理が可変の場合は、状態と処理を分離して実装すればOK。

問題は数が固定で状態別の処理が可変……って、これは数は固定だけど、実はEnumにするものじゃないんだよね、きっと。

うーん、なんか抽象的な話だなぁ……。

まとめると
状態数が固定なら、Enum。ただし状態数が拡張可能な場合はEnumジャダメ。
処理が可変な場合は、Strategyパターン?で分離しておくって感じ?
posted by すふぃあ at 15:17| Comment(0) | TrackBack(0) | プログラム