RADv7.0でEJB3.0プロジェクトをビルドする

TIPs Blogs

EJB3.0をお題とした「開発環境に頼りすぎずに、そもそもどういう仕組みなのかを学ぶことは大切ですね」というお話です。

文脈

普段IBMのIDEを使用されていない方にとっては、何のことやら分からない内容と思われますので、簡単に説明しますね。


RADとはRational Application Developerの略で、簡単に言えばeclipseの製品版です。このコにはアプリケーションサーバがついて来ていて、それがWebSphere Application Server、通称WASになります。RADv7.0には、WASのv5.0 v6.0 v6.1がついていますが、これらはいずれもEJB3.0に対応していません。ただし、WASに関してはIBMよりフィーチャーパックが配布されておりまして、それをあてることでEJB3.0のモジュールを含むプロジェクトがデプロイできるようになります。

問題：フィーチャーパックはWASにしか適用されない。

「WASに適用される」ということは、@Statelessを代表とする各種アノテーションを含んだjarファイルを入手することはできる＝実装することはできるようになる、ということです。「WASにしか適用されない」ということは、EARプロジェクトを作ろうとしたときに生成されるデプロイメント記述子(application.xml)のバージョンが1.4であって5ではない、ということを意味します。つまり、「実装はできるけれども、適切にデプロイできる形でビルドできない」という現象が発生してしまうのです。

試行錯誤

application.xmlのバージョンがあわないということは、GUIベースでプロジェクトを構築することがもちろんできない、ということです。それでもいくつか試すのですが。。。

とりあえず、version="1.4"でタグを書かずに試してみる

この場合、正常にインストールは完了しますが、EJBがデプロイされません。EJB3.0対応のコンテナであれば、インストール時に自動的にEARファイルの中身を洗ってくれそうなものですが、version="1.4"のapplication.xmlが入っているために、記述のないJARファイルはスルーしてしまうようなのです。それでも一応EJBのデプロイプロセスが動くのは、WARの中身でも探しているのでしょうか。

むりやりversion="5"のapplication.xmlを記述してみる

この場合はビルドした結果が壊れているようで、インストール時にエラーが出てしまいます。

解決

正解はもちろん、「あきらめて最新のRADv7.5をインストールする」なのでしょうが、とりあえず今回はその時間と気力がありませんでした。そこで原点回帰です。そもそもEJB3.0はejb-jar.xmlやapplication.xmlが省略できる仕様だったはず。いろいろと調べた結果、application.xmlが省略できるケースに関する以下の説明を見つけました。

application.xmlがEARファイルに存在しない場合のモジュールの判別ルールの詳細は、Java EE Specification V5.0, EE.8.4.2節 Deploying a Java EE Application, pp.166に記述がありますが、Configuration by Exceptionコンセプト（デフォルト・ルールを変更したい場合にのみ好みの設定をすればよいという考え方）に基づいた現実的なルールになっていることが分かります。以下にそのルールを抜粋します。

  1. EARファイル内で、ファイル拡張子が.warのものはWebモジュールとして扱う。ここで、そのWebモジュールのコンテキスト・ルート（要素の値）は、そのWARファイル名から.warを除いたものになる。
  2. EARファイル内で、ファイル拡張子が.rarのものはリソース・アダプタとして扱う。
  3. ディレクトリlib内にあるファイル拡張子が.jarのファイルは、そのアプリケーションで使用する拡張ライブラリとして扱う。
  4. ディレクトリlib以外にあるファイル拡張子が.jarのファイルは、以下のルールに従う：
    1. そのJARファイルのMETA-INF/MANIFEST.MFにMain-Class属性があるか、またはMETA-INF/application-client.xmlがあれば、そのJARファイルをアプリケーション・クライアント・モジュールとして扱う。
    2. そのJARファイルにMETA-INF/ejb-jar.xmlが含まれているか、またはEJBコンポーネントを示すアノーテーション（@Statelessなど）が付与されたクラスが含まれていれば、そのJARファイルをEJBモジュールとして扱う。
    3. 他のJARファイルは無視する。ただし、他のモジュールのMETA-INF/MANIFEST.MFのClass-Path属性で参照されていれば、拡張ライブラリとして扱う。

http://blogs.sun.com/nishigaya/entry/javaee5_rules_to_omit_dd

つまりはこのルールに従い、デプロイメント記述子を省略した形でEARを作ってあげれば良い、ということになります。もちろん開発環境からGUIで「EARの生成」というわけにはいかないので、それぞれのモジュールのJARやらWARやら必要なフォルダやらを一カ所にまとめてjarコマンドです。なお、この時のJARやWARに関しては開発環境から簡単に作ることができます。また、コマンドでEARファイルを作るやり方も上記ブログで説明してくださっています。

感想

OfficeのWordを使っていると時々叫びたくなるのは「ウラで何がおこっているのか分からないから」だと思います。開発環境にも多分同じことが言えて、理屈は分からないけれども手順を踏むことで目的が達成できる、という便利さをかなりの水準で実現してくれているように思います。これは非常に便利であり効率的でもあるのですが、同時に「それがないと何も分からない」という事態を引き起こしてしまっていると思います。実際におこっている現象の背後にあるロジックを常に意識することが大切だ、ということを改めて実感させてくれた出来事でした。

関連リンク