Seasar2/2.4セットアップではまったところ

またSeasar2をさわったときにはまる可能性があるので備忘録タグにしときます。

セットアップするに当たってみたドキュメントは以下の3つ

開発環境はNetBeans6.0。したがって便利なプラグインは用意されていないと思うので一から設定を組むことになります。

EJB3アプリケーションサーバーから切り離して開発をしたいため、EJB3の実装としてSeasar2を触るという位置づけです。できるだけSeasar2独自のものはさわらないこと、JPAglassfish上で動かすことを最終的な目標としました。とりあえず「Hello World」という文字がかえるだけのEJBを作成することにします。DBまわりは一切使いません。

まずWebアプリケーションのプロジェクトを作りました。Tomcat6はWindows版はいいのですが、Linux版がイマイチなのでGlassfish上で開発することになります。そうすると自動的にGlassfishのjar群がクラスパスにとおります。GlassfishEJBは日本語に問題があるためSeasar2EJB3をつかうことになります。そこでSeasar2のjarをライブラリ登録をします。当たり前ですが、EJBの実装がだぶることになって補完にしろ2重に表示されはじめます。ここでかなり嫌な予感がします。

セットアップのドキュメントを読むとわかりますが、どのjarがどういう動きをするというのがいまいちわかりません。たとえば「S2JTAを使う場合」とかかれていますが、これがどういったものかなどがわからないのです。データベースも扱わないサンプルプロジェクトですので、このへんはすべてなくてもいいのだろうと思いましたが、うごきません。JTAとかデータソースがとかえらーがでまくります。DB回り使わないのにこのへんが必須なのだろうかと思い、とにかくオプションとついてるjarをライブラリに追加しました。

ですが、動きません。jarを追加するたびにエラーは減っていくのですが、どうしてもひとつだけ解決できませんでした。

OGNLで例外が発生しました。理由は[ESSR0046]コンポーネント(ejb3tx)が見つかりません

というエラーが解決できなかったのです。この時点でSeasar2のエラーメッセージの意味がわからないのでjarが足りないのではないのかといろいろと探すことになります。検索してもこのエラーメッセージが出た人はほとんどいないようで参考になるものは出てきません。

どうやらdiconがほかに必要なのだとわかるのですが、そこに行き着くにはかなりの時間がかかりました。また、NetBeansはライブラリ登録にはjarとフォルダしか設定できません。ファイル単体は無理なようですね。

Hello World」という一文を表示するだけのわりにかなりのjar数になってしまいました。おそらくいらないものがたくさんあるでしょう。

一応動くことは動くので次にいきます。続いてjndiでアクセスできるかどうか試しました。

・・・動きません。

ejb3.htmlを見る限りなにもしなくてもinitかそのあたりで登録してくれるものだと勝手に想像していましたが、違うようです。ソースを追いかけたりするのがいいのでしょうが、ソースをダウンロードするにしてもファイルサイズが大きすぎておとせません。そもそも、このお勉強用のSeasar2もだいぶ古い2.4系をつかっています。ダイヤルアップでは最新版を落とすのは絶望的なサイズでした。最近急激にサイズが増えたようですね。

といまここで躓いています。


いろいろと苦労した点はNetBeans固有の問題もかなりからんでいます。使用するプロジェクトによって構成が大きく変わるからです。特にJPAがらみはNetBeansはオールインワンの癖にglassfishNetBeansとの相性が悪いせいで苦労します。別jarにするとSeasar2がらみの問題はおそらく消えますが、JPAがらみのほうはまともに動くようにみえません。EJBプロジェクトとWEBプロジェクトしかデータソースがらみが上手く設定できないようです。

glassfishを使っていながらEJBJPAなどJavaSE上で使おうというのがそもそもの間違いなのかもしれませんが、何度もいうとおり日本語がとおらないので日本人開発者は納得できるものではありません。Seasar2ならば日本語周りはばっちりだろうと思ってEJB3実装をそちらで動かせばカンタンに回避できるという甘い考えでした。

TomcatLinuxは6になってだめになったので、glassfishに移行し、軽さやわかりやすさでわりとすきなのですが、これは素直にJBOSSに移行しろというお告げなのでしょう。JBOSSにいったところでJPAの実装の違いなどもありますし、日本語が通る保証もないので茨の道になりそうですが。

DB本体などは日本語が問題出ることはほぼゼロになりましたが、postgreSQLにしろ周辺ツールで問題ありまくりで、どこが日本語が問題ないか、どう回避するかなどといったノウハウを蓄積するまでがかなり大変ですね。

日本語がとおるかどうかという基本的な、根本的なものですが、やはり日本人のつくったものしか安心できませんねぇ。でも人口だけでいったらマルチバイト圏は結構多いですよね。