トップ > Java > プレリュードは所詮プレリュード。だがそれがいい

プレリュードは所詮プレリュード。だがそれがいい

Java

プレリュードは所詮プレリュード。

「だがそれがいい」という人も多いかもしれないよ？というお話。

https://glassfish.dev.java.net/public/comparing_v2_and_v3.html


見てわかるようにGlassfish V3 PreludeはぜんぜんJavaEEを網羅し切れていません。JavaEE6どころかJavaEE5ですら完全には実装されていません。JavaEE 6に必要な機能はJAX-RSくらいしかまだ実装されていないのです（そのJAX-RSの実装であるJersey1.0ですらバグもちのようです）。

でも見方を変えると面白いことがわかります。アプリはwarファイルしかデプロイは出来ませんが、よく使われる機能としてJTAによるトランザクション管理とコネクションプーリング機能を持っています。もちろん、管理画面はすべてGUIによる管理が可能です。ログのローテートとかログレベルの動的な変更とかさまざまな便利な機能がGUIから操作可能なのです。

つまり、基本機能はTomcatでいいという人にうってつけなのです。ただ、Tomcatでいいという人であっても真っ当なコネクションプーリングとトランザクション管理が欲しいという人は多いはず。そしてこれらの便利なGUI管理ツールは日本語化されています。


それで上のほうで「だがそれがいい」といったのです。JavaEEのフル機能が入っていないからこそTomcatからの移行に最適です。Tomcatは5.5まではGUI管理ツールが一応搭載されていて、多少の操作は可能でした。しかし、6.0からはそれがなくなりました。

自前でやるにしても例えばTomcatではコネクションプールの設定などを行おうにもバージョンによって設定方法が異なったりします。今後もどんどん変わるかもしれません。JTAにおいては良く使われる機能なはずなのにTomcat上ではサポートしていません。DIコンテナ上でやるにしてもSpringは真っ当に実装されていないままだと思われます（過去に調べた範囲だとSeasar2は真っ当でした）。

コネクションプールはJNDIで取得するのがベストです。つまり、開発時と運用時でwarアーカイブの中身は替えないのが普通です。中の環境設定ファイルを変えるとなると他のファイルを間違っていじってしまうという可能性が残るため、普通に考えてテストしなおしが必要になってしまいます。

つまり、運用する場合サーブレットコンテナだけを使うとしてもすでにGlassfish V3に移行したほうがはるかにいいのです。GlassfishはサーブレットエンジンはTomcatを使用していますのでTomcatで動いていたものはまずそのまま動きます（そもそもTomcat自体sunから提供されたもののはず）。

入っているコンポーネントが少ないという音は非常にサイズが小さく小回りも聞くということです。すでに入っている各種JavaEEのコンポーネントを削除してさらにコンパクトにすることも可能なようです。


ちなみにプレリュードという名前がついているので未完成版に見えるかもしれません。たしかにJavaEEフル機能は入っていませんが、すでにちゃんとした製品版です。V2のように有償サポートも受けられます。



欲しい機能が以下のものだけでいいという人はGlassfish V2ではなく、Glassfish V3 Preludeがオススメです。小さいので起動も早く、フットプリントも小さいでしょう。

  • JavaEE5に対応したwarファイルがデプロイできること
  • コネクションプール機能があること
  • JTA機能があること
  • GUIによる管理が可能なこと

単純なwarファイルのデプロイ時間が異様に速いこと、再デプロイしてもセッションの維持をしてくれることはかなり便利だと思います。

実際のデプロイ時間はこんな感じ。

情報: Loading application WebApplication6 at /WebApplication6
情報: Deployment of WebApplication6 done is 93 ms

Webアプリの配備が100msもかからなくてもおどろかなーい。


再配備時のセッションの復元は思った以上に便利ですね。デバッガと同様にフィールドが増えたりメソッドが増えたりした場合はセッションに格納されたオブジェクトは復元できませんが、大概繰り返して実行したいときというのはロジックの修正がやはり多いです。

逆に言えばセッションスコープのBeanにロジックを書いているとメソッドの追加でもやり直しになるのでJSFとは相性がちょっと悪い気もします。ただ、プライベートなメソッドの追加ならば影響は無いようですのでそんなに問題は無いかな?StrutsとかSpringMVCなどアクションベースのフレームワークとかはわりとさくさく開発できるのではないでしょうか。


デプロイ一瞬、再デプロイでもセッションには情報は残っていますから、Seasar2のHotDeployに「比較的」近い感覚で開発が出来るのではないでしょうか。ちなみにNetBeans 6.5ではこのセッションを保持がデフォルトで有効になっています。NetBeans 6.5を落とした方はぜひお試しあれ。

あとはこのGlassfish V3のセッション保持機能がパワーアップしてちゃんとシリアライズと復元をしてくれたらこれほど便利なものは無いでしょうね。なんせ、フレームワークとかに依存しませんから。