開発日誌2002年5〜7月

敷居が高い J2EE 開発 (2002/05/23)
無償で手に入る J2EE 環境 (2002/06/06)
JOnAS がバージョンアップ (2002/06/10)
JBoss 3.0 を触ってみる (2002/06/12)
JBoss CMR を試す (2002/06/16)
JBoss CMR 解決！ (2002/06/17)
JBoss CMR 不具合 (2002/06/21)
JBoss Jetty の憂鬱 (2002/06/26)
JBoss 3.0.1RC1 (2002/07/02)

敷居が高い J2EE 開発 (2002/05/23)

　J2EE も 1.3.1 となり、今後ますます J2EE プラットフォームを用いたシステム開発が進むと考えられます。EJB が 1.1 から 2.0 となり、エンティティ Bean の CMP が機能強化されたことで、BMP をゴリゴリと書かざるえなかった状況も改善されるだろうと期待しています。CMP のほうが、圧倒的にコード記述が少なくて済みますし、配備記述をいじるだけで、データベースを入れ替えたり、テーブルを入れ替えることも簡単です。まあ、BMP でもこういったことは可能なのですが、自分で実装しなきゃならないわけです。BMP を書くという作業は、結局今まで通りデータベースと格闘してるわけで、J2EE という殻に閉じこめられたぶんだけ、よけいに面倒になったという現場の声があるのも事実です。それだけ、CMP というものが使い物にならなかったわけですが、今後、CMP が主流になってくれば、泥臭いデータベースとの格闘からおさらばできるわけで生産性もUPすることでしょう。マニュアル車からオートマ車へ乗り換えたような感覚でしょうか。。。ただし、CMP は、実行される J2EE コンテナの実装、性能に大きく依存しますから、ここが Application Server を開発する各メーカーの腕の見せ所となりますね。CMP 実行の最適化技術がどのくらい進んでいるかが鍵となるでしょう。J2EE 1.3.1 は、Sun で公開されてます。CMP の機能強化だけではなく、ローカルインターフェースのサポートや、メッセージ駆動型 Bean、JMS 等強化された機能の情報が手に入ります。

　さて、ちょっと古い話になりますが、４月初旬、オープンソースの Application Server として有名だった Enhydra が撤退するというニュースが流れました。Enhydra は Lutris という会社が中心となって立ち上げたオープンソースで、以前紹介した JOnAS とも関係があります。ですから、私にとっては少なからずショックなニュースとなりました。JOnAS のほうは、現在も進化を続けております。ただし、現状では、EJB 1.1 がサポートされているのみです。オープンソースでは、JOnAS の他に JBoss が元気ですが、こちらも、EJB1.1 のサポートのみです。一方、商用の Application Server は、今年中に 2.0 が完全にサポートされるものがほとんどです。現バージョンでも、先取りする形で EJB 2.0 が実装されてるものもあります。例えば WebLogic は 6.x から EJB 2.0 の利用が可能です。ただ、先取り実装しているぶん、最終版との差異が若干あります。やはり、商用の Application Server のほうが、オープンソースよりも一歩先んじている感は否めません。

　このような状況の中で、開発者の末端に位置する私たち、特にフリーの立場で仕事をしている者にとって、現在の J2EE 開発は敷居が高すぎます。開発環境を手に入れるためのコストが高すぎるのです。Application サーバーの開発版（ライセンス）を手に入れるだけで、40～50万かかります。J2EE 開発環境(IDE) を手に入れるとなると、さらに、10～30万かかるのです。お金をかけずに、J2EE 1.3.1 対応の開発を行おうとすると、J2EE SDK をダウンロードして、エディタでゴリゴリと書かないといけません。Bean の生成のために、スクリプトを書くまでが精一杯。web.xml や ejb-jar.xml 等の配備記述子を書くのは結構うんざりです。J2EE 開発環境(IDE)があれば、Bean はウィザード形式で生成できますし、同時に配備記述子も自動生成されます。しかも、Application Server への配備も一発でできるので、開発効率がすこぶる良いのです。こういった環境がないまま開発を進めるのは、かなり苦痛な状況となります。

　では、我々のような下々の者はどうすればよいのか？ J2EE の開発は、期間限定の試用版やベータ版を細々と使わせていただく以外に手はない状態です。「男なら J2EE SDK のみで開発するもんだ」なんて粋がったところで、くだらんミスばかりやらかして、開発効率は悪いものとなるでしょう。また、ターゲットとする Application Server の独自の配備記述については、J2EE SDK だけではどうすることもできません。

　私も今までに、Application Server や開発IDEの試用版やベータ版を色々と試してみました。それらの中で使えそうなものをまとめてみましたので、J2EE の開発に興味がある方は参考にしてください。

Application Server	開発環境	特徴
Oracle OC4J	JDeveloper	OC4J は OTN で手に入ります。OTN Japan からではなく、本家からだと最新版を手に入れることができます。JDeveloper も同様です。OC4J は、EJB 2.0 仕様を一部サポートしてます。J2EE 1.2 に完全対応していますが、1.3.1 は一部対応です。JDeveloper Ver.9.0.2 は、残念ながら EJB 1.1 対応の Enterprise Bean の作成しかできません。この点はちょっと残念なのですが、JDeveloper は OC4J を内部に持ち、Web Server, Servlet も内部に持ってますので、JDeveloper だけで J2EE の開発が可能である点が魅力です。今後、EJB 2.0 に完全対応すればもっと魅力的な開発環境となるでしょう。UML を利用した開発機能もあり、なかなかおもしろいです。WebLogic 6.x へのデプロイもできるようになっているのですが、WebLogic 6.1 で試しましたがうまくいきませんでした。EJB 1.1 の Bean を生成するにもかかわらず、WebLogic への配備記述は 6.1 用（EJB 2.0を要求）となっており、不整合がおこってます。しかも、かなり記述が足りません。EJB 2.0 に Bean を記述しなおして、配備記述子の不足分を自分で書けば問題は解決するのですが、そうすると、JDeveloper 内の OC4J でうまく動かなくなるという事態に陥ってしまいます。　EJB 1.1 ベースの開発で、Oracle をデータベースとして考えているならば、JDeveloper はお勧めです。OC4J の Application Server としての実力は未知数ですが、カタログスペック的には、他社と遜色のないものです。OTN はドキュメントも整理され、充実してます。OTN Japan には日本語版のマニュアル（最新とは限らない）や技術情報が用意されており開発者を支援してくれます。昔、Oracle と言えば閉鎖的なイメージが強かったのですが、ここ数年で随分オープンになりました。OTN は登録が必要ですが無料ですから、Oracle に関わっている人は是非覗いてみられることをお勧めします。
IBM WebSphere 4.0	WebSphere Studio 4.0.3	IBM WebSphere の開発は WebSphere Studio で行うのが最適です。なぜならば、WebSphere の開発情報が少ないのです。IBM サイトにはマニュアルが公開されてません。紹介記事やチュートリアル、サンプルがあちこちにあるだけでしす。Oracle のように、マニュアル、技術情報として整理されてないのです。ですから、WebStudio なしで開発することは非常にシビアです。この点は、Oracle を見習って情報公開して欲しいところです。開発環境としては、Visual Age for Java プロフェッショナル版が、WebSphere をサポートしており、Visual Age for Java IDE内で開発可能です。しかし、Visual Age for Java は癖のある開発ツールでして、万人向けとは言えないかも。。。　というわけで、WebSphere とおつき合いするためには、少なくとも WebSphere を購入するのがお勧めです。幸い 10数万で開発ライセンス版が手に入ります。正規ユーザーなら、マニュアルとサポートが手に入ります。しかし、WebStudio はかなり高いので手に入れるのは難しいでしょう。こちらはあきらめるか試用版を使わせて頂くことになります。試用版はリミットがありまして、大規模サイトの開発は無理なようになってますので、小規模なものを作ってみて、どういうふうにソースが生成され、配備記述されて配備されるのかを学ぶことになるでしょう。ある程度習得したら、エディタでゴリゴリやるしかないと思います。
BEA WebLogic 6.1	Forte for Java EE 4.0 EA	BEA WebLogic 6.1 は、30日限定試用版を使うか、40数万払って、開発ライセンス版を手に入れるしかないでしょう。試用版、開発版は接続数の制限がそれぞれ、１、５となっているそうです。コスト面では開発者に優しくない BEA です。が、同社の本家、日本サイトともにマニュアルや技術情報のドキュメントが整理されています。WebSphere のように、開発情報の少なさで苦労することはありません。また、Application Server としての性能や扱いやすさも秀逸だと思います。　開発環境としては、WebLogic Workshop というものがあるようですが、私は使ったことがありません。WebLogic は業界の老舗ですから、開発IDEは WebLogic 対応のものが結構あるようです。しかしながら、どれも、数十万します。（涙）そこで、目をつけたのが、Forte for Java EE 4.0 の Eary Access 版です。評価版ということで、現在は、 2002/08/31 まで試用できるものが公開されてます。EJB 2.0 に対応しており、WebLogic との連携もバッチリでして、IDE 上で開発、配備まで実行できます。Forte for Java EE も購入するとなると数十万する代物です。今後期待するとすれば、Forte for Java のベースである、オープンソースの NetBeans ですが、どうでしょうかね。最近の NetBeans は IDE開発環境プラットフォームとして、Java だけではなく、他の言語のプラットフォームとしても利用できるように、完成度を高めていく方向になってきたようです。そういう意味では、あまり期待できないかもしれません。
JOnAS	なし	以前紹介したので詳細は語りません。最新のバージョンには、Tomcat が含まれるようになりました。性能的には商用のものには到底かないません。特に CMP を利用するとはかなりのオーバーヘッドを感じます。データベースへのアクセスが頻繁に起こるようです。　開発環境としては、現状 IDE は存在しないと思います。代わりに、Bean の雛形を作成できるシェルスクリプトと、デプロイツールが付属してます。その他、有志によるツールがいくつかあるのみです。
JBoss	不明	私自身は全然触ったことないのですが、結構元気なプロジェクトのようです。少ないリソースで動かすことができるのが特徴のようでして、EJB コンテナ環境のみのようです。興味はあるのですが、現時点では勉強不足です。

　「IIS がないじゃないか」と怒られそうですが、IIS は皆さんよくご存じでしょうし J2EE とは無縁ですから、からかまわんでしょう。Oracle 以外の各社には、安価な開発環境の提供をお願いしたいものです。でないと我々のような開発者は、J2EE 開発に参入することが難しいです。なるほど、だから世の中 IIS だらけになってきたんでしょうね。これでいいんでしょうか？

無償で手に入る J2EE 環境 (2002/06/06)

　前回、J2EE 開発環境は敷居が高いと述べましたが、その後、無償で手に入る J2EE アプリケーションサーバーについて、いくつか情報を得ましたので紹介します。

　まず、HP が提供している HP-AS という、ライセンス無償のアプリケーションサーバです。日本ヒューレット・パッカードのサイトから、日本語版とドキュメントをダウンロードできます。J2EE 1.2 ベースに、一部 1.3 対応という感じです。EJB は 1.1 ベースで、 2.0 の CMP 対応は、WebGain の TopLink が必要との記述がありますので、CMP 2.0 対応の開発は無理っぽいです。ただ、他社も完全対応するのは、次のバージョンですから、決して遅れをとっているわけではありません。（WebLogic は現バージョンでも CMP 2.0 が使えますが。。。）

　次に、オープンソースの JBoss です。ちらっとプロジェクトを覗いてみました。開発スピードが JOnAS と比べて断然速いようです。（笑）本当に元気なプロジェクトですね。「BEA キラー」という言葉が出てくるあたり、その意気込みが感じられます。最新の JBoss 3.0 では CMP 2.0 が使えるようです。ドキュメントは英語ですが一通りあるようです。ただ、一部は有償のようでして、例えば、今一番見たい CMP 2.0 のドキュメントは有償でしか手に入らないようです。$10.00 ですので購入してもよい値段なんですけど、もし、一般的な CMP 2.0 の開発について書かれてたらがっかりですので、購入は見合わせました。その他、有償ドキュメントの提供として、半年間、１年間の最新ドキュメントの提供というものもありました。こういう形で寄付を募っているのでしょう。

　さて、今後 JBoss は、もう少し追っかけてみようかなと思ってます。JOnAS の進展次第ってところもありますけど、現時点では JBoss の勝ちのようです。

JOnAS がバージョンアップ (2002/06/10)

　JOnAS がバージョンアップし、EJB2.0 対応となった模様です。また、Tomcat 4.x を組み込みできるようになったようです。どうしても JBoss と比べてしまうのですが、これでやっと、サポートされた規格は同じ程度になったと思います。しかし、見劣りする点がいくつかあります。ホットデプロイできないし、クラスタ対応も JBoss が一歩リードしてます。

　ただ、WebLogic なんかと比べると、どちらも１０歩ぐらい遅れてるんですよね。ってなこと言って、部外者が水を差すのもあれなんで、あまり語るのも気が引けるところですが、WebLogic なんか見てると、やはり高い金出して買うだけの価値があると感じます。それだけ最適化されてるんですよね。例えば、EJB って、RMI を使ったリモート呼び出しされる仕組みになってるわけですが、これって、同じマシン内、コンテナ内に呼び出し元と呼び出される側が存在する場合、オーバーヘッドが大きくて性能を落とす要因になります。WebLogic は、ここんところをうまく解決してて、ローカルで呼び出してオーバーヘッドを無くす工夫をしてます。J2EE 1.3 では、この解として、EJB 2.0 で、ローカルインターフェースが定義されてますが、WebLogic では既にこの問題を、実装で解決しているってことなんです。また、Entity Bean で、データを更新していないのに、コンテナから呼び出しが煩雑に発生するケースがあります。これは、isModify() メソッドで、更新されているかどうかを返すようにプログラミングすることで回避するのですが、WebLogic 6.x では、これも必要ありません。（昔は必要だったようです） WebLogic ではコンテナがしっかりと面倒を見てくれてるんですよね。その他、当然ですが、ホットデプロイは当たり前ですし、クラスタ構成も問題なく動きます。

　と、気が引けると言いながらも、色々とマイナス面を書いてしまいましたが、勿論、JOnAS, JBoss 等、オープンソースのアプリケーションサーバーをコケにしたいわけではありません。むしろ、商用アプリケーションサーバーに匹敵するものになって欲しいと切に願っているわけです。J2EE のリファレンス実装は、今のところ Sun ががんばってやってますけど、そろそろ、JBoss なんかに任せてしまえば面白いのになあなんて無責任なことを言ってみる。。。

JBoss 3.0 を触ってみる (2002/06/12)

動かすのは簡単

　JBoss を動かすのは簡単です。まず、JDK 1.3.1_03 はインストールしておきましょう。（笑）後は、インストールは、JBoss本家から、アーカイブをダウンロードして解凍する。環境変数 JBOSS_DIST に解凍したディレクトリをセットする。 %JBOSS_DIST%bin にある、run.bat (UNIX の場合は run.sh) を動かす。以上です。ブラウザから、http://localhost:8082/ にアクセスして、Agent View が表示できたなら、一応動いていることは確認できるでしょう。念のため %JBOSS_DIST/server/default/log に格納されるログも見ておきましょう。エラーが発生してなければ問題なしです。

だから、どうした？

　「ワーイ、動いた動いた」で終わりなら、単なるインストールオタクになってしまいます。とりあえず、何か動かすものはないか？と、見つけたのが、Neverbird Project です。JBoss の日本語ドキュメント、サンプルを作成するプロジェクトだそうです。SOURCE FORGE.jp の Neverbird に登録されているサンプルを頂いて試してみることにしました。

サンプルをBUILDする

　私がGETしたアーカイブは、100beans-20020605.zip です。README.txt を読むと、Ant 1.4.1 と JUnit 3.7 が必要とのこと。build.xml の中身を見ると、先頭のほうで、環境変数 JBOSS_DIST, LOG4J_HOME, JUNIT_HOME が必要とわかりました。が、log4j が必要とは README に書いてない。。。そこで、build.xml を調べましたが、log4j は必要ない（と言うより、JBoss にバンドルされているものがクラスパスに設定されている）ようなので、Ant と JUnit だけをインストールして、環境変数を設定しました。インストールのコツですが、build.xml では、<junit> タグを使って、JUnit を使うように書かれてますので、%ANT_HOME%lib に、jakarta-ant-1.4.1-optional.jar をコピーしておく必要があります。後は、ant と入力すればコンパイルからデプロイまでやってくれます。

サンプルを動かす

　JBoss を起動したまま、サンプルを BUILD したら、ホットデプロイにより自動でデプロイされます。build.xml がやっていることは、コンパイル後に、まとめられた jar ファイルを、%JBOSS_DEST%/server/default/deploy にコピーしているだけです。コピーされた時点で、JBoss が自動認識してるってことです。ちなみに、配布された jar を削除すると、自動的にアンデプロイされます。ちょっと感動しました。さて、エラーも出ずに正常にデプロイできているならば、ちゃんと動くことを確認しなければなりません。README に従い、ant test とやると、一応終了したものの、何やら color.sql を動かせと言ってます。color.sql の中身を見ると、JB_COLOR テーブル作成の DDL と、テストデータの INSERT 文が入ってます。ちょい待て。。。「JBoss には、データベースが内蔵されてるのか？」と何も知らなかった私。と、改めてサンプルを見ると、Entity Bean のサンプルもしっかりと入っていることに気づき、「おお、データベースが動いてるんだ」と確信しました。（爆）しかし、いったい、このデータベースにどうやってアクセスしたらよいものか、皆目検討もつかない始末。そこで、JBoss のディレクトリの中を彷徨うこと小一時間（なわけない）。%JBOSS_DIST%/server/default/deploy/hsqldb-service.xml を発見。ここに JDBC ドライバの設定が記述されてました。その他、%JBOSS_DIST%/server/default/conf にも、standardjaws.xml、standardjbosscmp-jdbc.xml という関係ありそうなファイルを発見しました。で、わかったのは「Hypersonic SQL」というデータベースがバンドルされているということ。「java ベースのデータベースなら、データベースマネージャのようなものが存在するはず」との思いから起動バッチ（シェル）がないか bin を見ましたけど、それらしきものは何もありません。そこで、lib ディレクトリを調べると、%JBOSS_DIST%/server/default/lib に hsqldb-plugin.jar と hsqldb.jar を発見しました。名前とファイルサイズから察するに正解は hsqldb.jar のほうだと考えて、jar tvf hsqldb.jar | more で中身を覗いてみたところ、org/hsqldb/util/DatabaseManager.class という、データベースマネージャーらしきクラスを発見。さっそく、java -cp hsqldb.jar org.hsqldb.util.DatabaseManager とやってやると、ビンゴ！ HSQL Database Manager が起動しました。まずは、ログイン画面に接続情報を入れないといけません。これは、先ほど発見した、hsqldb-service.xml の記述に従えばよいはずです。Type を選択しなきゃならないんですが、これは、「HSQL Database Engine Server」を選択。Driver は、デフォルトの「org.hsqldb.jdbcDriver」のまま。URL:は、jdbc:hsqldb:hsql://localhost:1476 を指定。User は、デフォルトの「sa」のまま。Password は「なし」です。これで見事、接続に成功しました。では、さっそく、color.sql を投入。ところがエラーが発生しました。Text って型はないと怒られました。どうも、PostgreSQL あたりを想定した CREATE 文が書かれているみたいです。Text を VARCHAR に修正して実行したところ、正常に作成することができました。

　サンプルを何度か動かしてみて気づいたのですが、テーブルは、デプロイ時に自動作成されているようです。この仕組みは、各サンプルBeanの jbosscmp-jdbc.xml に、

<create-table>true</create-table>
<remove-table>true</remove-table>

と記述があるのが鍵のようです。JBoss を終了すると、テーブルは削除されるんでしょう。そのため、先ほどの color.sql は、起動後に毎回実行してテストデータを入れる必要があります。

Hypersonic SQL を Oracle に入れ替える

　日頃使い慣れたデータベースを使いたいというのは自然な欲求です。というわけで、さっそく、日頃使い慣れた Oracle9i を使うように設定の変更に挑戦しました。%JBOSS_DIST%/docs/examples/jca に代表的なデータベースの設定ファイルが存在します。oracle-service.xml を %JBOSS_DIST%/server/default/deploy にコピーして、JDBC ドライバの設定を変更します。変更する箇所は、

        <attribute name="ManagedConnectionFactoryProperties">
          <properties>
            <config-property name="ConnectionURL" type="java.lang.String">jdbc:oracle:thin:@youroraclehost:1521:yoursid</config-property>
            <config-property name="DriverClass" type="java.lang.String">oracle.jdbc.driver.OracleDriver</config-property>
            <!--set these only if you want only default logins, not through JAAS -->
            <config-property name="UserName" type="java.lang.String">yourname</config-property>
            <config-property name="Password" type="java.lang.String">yourpassword</config-property>
          </properties>
        </attribute>

です。JDBC URL と UserName, Password を設定します。Oracle thin JDBC ドライバの classes12.jar は、%JBOSS_DIST%/server/default/lib にコピーしておきます。

目的は、Hypersonic SQL を Oracle9i に置き換えてしまいたいということなので、JNDI Name を DefaultDS に変更してしまいます。

        <attribute name="JndiName">DefaultDS</attribute>

oracle-service.xml の上のほうに、「Include a login module configuration named OracleDbRealm. Update your login-conf.xml, here is an example for a ConfiguredIdentityLoginModule」とコメントがあります。

    <application-policy name = "OracleDbRealm">
       <authentication>
          <login-module code = "org.jboss.resource.security.ConfiguredIdentityLoginModule" flag = "required">
             <module-option name = "principal">yourprincipal</module-option>
             <module-option name = "userName">yourusername</module-option>
             <module-option name = "password">yourpassword</module-option>
             <module-option name = "managedConnectionFactoryName">jboss.jca:service=LocalTxCM,name=OracleDS</module-option>
          </login-module>
       </authentication>
    </application-policy>

これを編集して、%JBOSS_DIST/server/default/conf/login-conf.xml に追加するべしとのことです。ただ、これは、 RDBMS Realm を使う時に必要だと思うので、今のところあまり関係ないように思います。私には、JBoss のセキュリティ設計がどのようになってるのか知らないので、この点は今後の課題となります。例えば、WebLogic では、Realm として、ファイル（デフォルト）、ldap V2、WindowsNT、UNIXとの統合、そして RDBMS が使えます。アプリケーションサーバーの開発には、セキュリティのお話は避けて通れない道です。WebLogic はファイルレルムがデフォルトでして、会員制サイトのようにたくさんのセキュリティ情報を扱うには向いてません。WebLogic の RDBMS レルムはサンプルソースが提供されており、それをカスタマイズして使用することになります。JBoss で、RDBMS Realm が簡単に使えるならば、会員制サイトの構築も楽なはずです。

　さて、あと、変更が必要と思われる設定ファイルは、%JBOSS_DIST/server/default/conf の、standardjaws.xml と standardjbosscmp-jdbc.xml です。Java, JDBC, SQL のデータ型のマッピングを記述して、DefaultDS と関連付けます。

   <datasource>java:/DefaultDS</datasource>
   <type-mapping>Oracle9i</type-mapping>

先頭に、このように記述します。DefaultDS に、Oracle9i を関連づけます。Oracle9i のマッピング記述が、standardjaws.xml にありません。が、standardjbosscmp-jdbc.xml にありますので、それをコピーして作りました。

　これで、Oracle を DefaultDS として使えるようになるはずです。先ほどのサンプルが普通に動くはずです。（笑）しかし、そううまくいかないのが世の常。。。以下のような問題点が出てきました。

Oracle で認められないカラム名が使われている。(DATE と COMMENT)エラーとなる Bean の jbosscmp-jdbc.xml で実際のカラム名とのマッピングを追記修正してやる必要があります。
Java の char 型が「キャストできない」と実行時エラーとなります。Java, JDBC, Oracle のにマッピングに問題がありそうです。とりあえず、ソースの char を String にしてやれば動きます。Oracle JDBC ドライバのドキュメントを見ると、どうやら char はマッピングできない模様です。上のstandardjaws.xml と standardjbosscmp-jdbc.xml で記述してあるマッピングに問題があるような気がします。char -> BYTE にマップすれば動くかもしれません。
Timestamp 型がうまく渡らない？Timestamp 型（ms まで格納可能な型）が、Oracle にうまく渡ってないようです。Oracle9i は TIMESTAMP(9) に、マップされてます。（上のstandardjaws.xml と standardjbosscmp-jdbc.xml に記述されている）これはドライバの問題かな？この Timestamp を使った Bean に問題が発生ているようです。どのように回避したらよいかわかりません。秒レベルのDATE 型までしか持たない RDBMS もありますので、TIMESTAMP のみを頼る実装をしないほうが良いという見方に立てば、サンプル自体をなおしたほうが早いかも。。。

まあ、サンプルということで、これ以上追いかけるのは止めておきますが、興味のある方は解析してみてください。各 Bean についてポイントは、ここの一覧記述されてます。ポイントと、ソースや DD を照らし合わせて、「なるほど」と勉強させて頂くことが重要だと思います。Oracle で動かすよりも、PostgreSQL で動かした方が良いようです。

純正サンプル（？）を動かそう

　SOURCE FORGE.net の JBoss.org には、JBoss.3.0Template.Project.zip というサンプルが登録されています。これは、XDoclet というオープンソースを使って、Bean のソースから、他に必要なインターフェース関係のソースと、ejb-jar.xml 等の必要な配備記述子を自動生成してしまうというものです。「JBoss 3.0 Quick Start Guide」にも Template Project として紹介されています。XDoclet が秀逸なのは、J2EE 規格で規定されている ejb-jar.xml だけでなく、ベンダー依存のDD も生成してくれるところです。Apache Soap, Bluestone（前回紹介したHP-ASの前バージョン）, Castor, JBoss, JRun, MVC Soft, Orion（Oracle OC4J）, Struts, Weblogic, WebSphere に対応しているようです。

　XDoclet は、クラスやメソッドのコメントに、JavaDoc に似た @ejb: で始まる独自のタグを書き、Ant の xdoclet サブタスクが、これらタグを解析して、xdoclet タグ内で指示した方法やバージョンで、Home, Remote インターフェースのソースと配備記述子を生成します。JBoss.3.0Template.Project.zip には、Entity Bean, Session Bean, Message Driven Bean と、テストクライアントのサンプルが入ってます。このサンプルは、Ant で生成、コンパイル、デプロイまで自動でやってくれ、実際に動く完結したサンプル（テンプレート）です。「これで J2EE 対応 IDE を買えない貧乏人にも一筋の光が見えた？!」と思いましたね。（笑）とは言うものの、これだけでは、さすがに、本当に必要十分なものが生成されるのか？という疑問は拭えておりません。「疑い深い && 勉強不足」ですので、とりあえず「こいつを動かしてみよう」ということだけに注力することにします。応用編は、ご自身でどうぞ。テンプレートですから、これをベースに実際に必要なものを作成していくというのが基本でしょう。いずれにしても、高価な J2EE 対応の IDE をお持ちの方には関係のないお話です。IDE 用の JBoss 対応のプラグインが存在するようですので探してみてください。今のところ前のバージョンのものが多いようですが、そのうちに 3.0 用のものも出てくるでしょう。

　さて、Template Project の話に戻ります。先のアーカイブを解凍すると、まず、.ant.properties の内容を編集する必要があります。jboss.home, xdoclet.home, type.mapping, datasource.name プロパティを環境に合わせて編集してやります。後は ant すれば、build 以下に必要なソース、配備記述子等が生成され、コンパイル、デプロイまでやってくれます。正常にデプロイされると TESTENTITY というテーブルが作成されるはずです。build/bin の下の run-client.bat(run-client.sh)を動かしてやれば、TESTENTITY にプライマリキーがユニークに生成されてデータが追加されます。また、Message Driven Bean が呼び出され、コンソールに TestSessionBean.ejbCreate() と出力されるはずです。「おお！JMS もちゃんと動いてる！」と感動しました。　

まだまだ課題がいっぱい

　私も、やっと JBoss の入り口に立てたような気がします。JBoss で問題となるのはドキュメントとサンプルですね。無料で手に入れることができる、まとまったドキュメントは少ないです。まとまったドキュメントは有料で手に入れるしかありません。3.0 がつい先日リリースされたばかりなので、現状では 2.4 ベースのドキュメント＋αのようです。改訂を待ったほうが良いのか思案のしどころです。６ヶ月($60.00)、１２ヶ月($120.00)のサブスクリプションならば、期間内なら無料でバージョンアップを受けることができるようです。

　実際に開発するには、まとまった情報が簡単に手に入らないと難しいです。WebLogic は高価だけど、開発者には優しくて、マニュアルは全て開示されてます。しかも日本語で。これは、アプリケーションサーバーをプラットフォームとする開発者にとって大きなプラスです。サーバーの管理も Web ベースで直感的に簡単に操作できます。設定ファイルを直に触る必要はないのです。WebSphere も WebLogic には負けますが、それなりに情報が豊富にありますし、管理も楽です。JBoss の強みはオープンソースであることです。でも、私のようなへたれ開発者には、JBoss 自体の開発や仕組みに興味があるわけでもなく、JBoss 上でうまく動くものを作るための情報が必要なだけです。そのために仕組みの理解が必要ならば、それは厭いませんけど、JBoss の仕組みを延々と解説されるようなドキュメントなら必要性は感じません。有償のドキュメントのインデックスを見てると、そういった臭いがするんで購入を躊躇してます。

　J2EE の開発自体が主眼であれば、わざわざ JBoss を使う必然性はないと思います。正直言って、WebLogic や WebSphere をターゲットとした開発のほうが楽だと感じます。気兼ねなく開発したいなら HP-AS でも良いでしょう。アプリケーションサーバー自体をうまく動かすことに興味があるわけではないのですからね。へたれ開発者から見た JBoss は、ここらへんのバランスがちょっと悪いです。たぶん高度な開発者がターゲットなんでしょう。JBoss の設計は洗練されているので、不必要なサービスを取り除いて必要最小限の組み合わせで運用させるようなことが可能です。こういう志向を持って、JBoss を利用するのが正しい姿なのだと思います。

　というわけで、「へたれ開発者には JBoss は難しい。」という結論でした。（笑）

JBoss CMR を試す (2002/06/16)

　JBoss 3.0 の特徴は、EJB 2.0 に対応していることです。EJB 2.0 の中で特に重要だと思うのは、CMP 2.0、CMR 、EJB-QL だと思ってます。CMR (Container-Managed Relationship)とは、CMP エンティティ Bean どおしの関係を定義しておくと、コンテナが永続化の面倒を見てくれるというものです。例えば、生徒を表す Student という CMP と、その生徒が持っている本を表す Book という CMP があったとします。一人の生徒は通常、複数の本を所持してます。つまり、1:N の関係が成り立ちます。また、生徒に割り当てられたロッカーを表す Locker という CMP があったとすると、生徒とロッカーの関係は、1:1 の関係が成り立ちます。さらに、生徒を教える先生を表す Teacher という CMP があったとすると、生徒と先生の関係は、M:N の関係が成り立ちます。EJB 1.1 では、このような関係を表す術はありませんでした。CMR で、それが可能となったわけです。実際、CMP エンティティ Bean は、RDBMS のテーブルにマッピングされるのが普通です。RDBMS では、テーブル間の関連づけを行うことができるわけですが、CMR によってテーブルどおしの関係が自然に表現でき、操作できるようになったわけです。EJB-QL は、RDBMS で言うところの SQL にあたります。CMR により、参照 Bean の連結による問い合わせもできるようになりました。EJB-QL は、SELECT, FROM, WHERE の節によって構成されます。SQL文とよく似た構文となってます。

　と、能書きはこれぐらいにして、JBoss の CMR は、いかがなものかと、ちょっと試してみました。結論から言うとダメでした。（泣）詳細を話すとメチャ長い話になるので、かいつまんで話をします。まず問題は JBoss の CMP 2.0、CMR のドキュメントは有償でしか手に入れることができないことです。ただ、インターネットをあちこち探してみますと、いくつか使い方の断片を見つけることができました。また、XDoclet を使うと、JBoss 独自の配備記述子を生成してくれます。ですから、なんとかなるだろうという甘い考えで実験に着手したのです。実験にあたり、J2EE の規格の範囲で正しく動くものを作っておこうという意味で、WebLogic で動作する StudentBean と BookBean の 1:N の関係を持つ２つの CMP Entity Bean を作成しました。テスト用のクライアントプログラムが動作した段階で、作成した２つの Entity Bean と ejb-jar.xml が正しいことが確定です。さて、JBoss で試すにあたり問題となるのが、JBoss 独自の配備記述子です。一番問題となるのが、データベーステーブルとのマッピング、リレーション関係を記述する jbosscmp-jdbc.xml です。これは、XDoclet に必要な @jboss: タグをコメントに埋めて生成し、コンパイル、デプロイを繰り返して、エラーが出なくなるまでトライ・アンド・エラーを繰り返しました。そして、ようやく、正常にデプロイできるレベルまで持っていくことができたのです。（万歳！）ところが、テスト用のクライアントを動かすとうまく動かなかったのです。

　「何が問題か？」テスト用クライアントは、「生徒を１人生成」「本を３冊生成」「生徒に３冊の本を関連づける」という単純な動作をするものです。この中で、３番目の「関連づけ」ができなかったのです。もう少し詳しく言いますと、Student CMP Bean には、複数の本を get, set するために、

public abstract java.util.Collection getBooks();
public abstract void setBooks(java.util.Collection pBooks);

という抽象メソッドを書きます。CMP 2.0 では、abstract になっているのがミソで、コンテナが実装してくれるという話は別にして、実際に本を割り当てるユーティリティメソッドとして、

public void assignBook(Book b)
{
    java.util.Collection c = getBooks();
    c.add(b);
}

というメソッドを作ってます。Student CMP Entity Bean を create して、Book CMP Entity Bean を３つ create した後に、この、assignBook() を使って本を割り当てるという手順になるのです。Book にマッピングされるデータベーステーブルには、「生徒コード」フィールドが存在し、生徒テーブルの「生徒コード」に対して、Forignkey が張られます。（本テーブルは本の種類ではなくく、同じタイトルの本でも便宜上別物として考えてます。テストサンプルですから許してください）ですから、実行後には、３冊の本のレコードの「生徒コード」に１人の生徒コードが書き込まれることが期待されるのです。実際、WebLogic では、そのように動作しました。しかし、JBoss は生徒コード Null のままでした。（泣）

　原因は何なんでしょう。配備記述子に問題があるというのが一番可能性が高いのですが、正式なドキュメントを読んだわけでもありませんので検証は不可能です。次に考えられるのが、WebLogic の実装が間違っている？これは、J2EE 1.3 の仕様書を調べないとわかりません。でも、どうでしょう。この可能性は低いような気がしてます。一番堅いのは、J2EE 1.3 SDK で確認することす。この点は検証方法が悪かったと、ちょっと反省。。。

　てなわけで、JBoss は、やっぱり難しい。。。「オープンソースなんだから、ソースを追いかけろ！」って、つっこみは勘弁してくださいませ。。。有償のドキュメントに JBoss 3.0 の CMR の jbosscmp-jdbc.xml の記述方法が書いてあるならば買います！でも、それさえもわからないんですよね。。。どなたか知ってたら教えてくださいませ。

JBoss CMR 解決！ (2002/06/17)

　上の JBoss での CMR がうまく動かない件は解決しました。何が問題だったかのか？上のテストでは、クライアントプログラムで、Book を生成して、Student の assignBook() を使って Student と Book を関連づけてました。WebLogic 6.1 だとこれで動くわけですが、JBoss ではテストクライアントのほうで、RMI のエラーが発生して動きませんでした。そこで、色々とインターネットを彷徨って調べてみると、こういうケースでは、assignBook() の中で、Book を生成している例を見つけました。そこで、クライアントで Book を生成している部分を assignBook() に移してやってみましたが、今度は、JBoss が実行時にエラーを吐きます。そこで、もう一歩進めて、EJB 2.0 で導入された「ローカルインターフェース－ローカル Bean」を使うと、問題なく実行できたのです。assignBook() は以下のようなコードになりました。

   public void assignBook(String pBookID,String pBookName)
   {
        try {
                InitialContext ctx = new InitialContext();
                Object h = ctx.lookup("ejb/entity/BookLocal");
                BookLocalHome bookHome = (BookLocalHome)
                                PortableRemoteObject.narrow(h,BookLocalHome.class);
                BookLocal b = bookHome.create(pBookID,pBookName);
                this.getBooks().add(b);
        } catch( Exception e ) {
                e.printStackTrace();
        }
   }

　なぜ、先の方法ではダメなのかが、わかっていません。（爆）今回の方法でも、リモート呼び出しだとエラーとなることから、何か大きなチョンボをしているような気がします。（配備記述子か？？？）RMI のエラーってのが気になるところなんですよね。設定か、セキュリティがらみのような気もするのです。

　とにかく、「JBoss 3.0 で CMR 試す」は、結果ＯＫ！ということに落ち着きました。JBoss が落ち着いたところで、JOnAS はどうなんだろうという思いがあったのですが、JOnAS 2.5 リリースノートをよく読むと、「Restriction: EJB 2.0 persistance is not supported in this version. 」とありました。ということは、CMR なんてまだサポートされてないってことですよね。。。EJB 2.0 のローカルインターフェース、Bean はサポートされてます。また、ejb-jar.xml の ejb-jar_2_0.dtd は理解できるようです。でも、それだけじゃねえ。。。つまり、JBoss のほうが、一歩も二歩も先をいっているってことですね。「ようやく同じ土俵に登った」なんて思ってましたが、大きな勘違いでした。（笑）

　ところで、J2EE の無償の開発環境として、「JRun 4」があるという情報を頂きました。JRun って今、Macromedia が扱っているですね。知りませんでした。Servlet の聡明期、Tomcat なんて有名じゃなかった頃は、Apache + JRun で Servlet を動かしてた方もいるんじゃないでしょうか。当時は、Sun の servletrunner、Java Web Server か、Apache + jserv か、Apache + JRun という環境ぐらいしかなかったと思います。恥ずかしながら、JRun が J2EE の道を歩んでいたとは知りませんでした。さて、JRun 4 開発ライセンス版は、なんと無償という太っ腹です。ただ制限として、接続がローカルマシンに限定されるようです。私も早速インストールしてみましたが、管理コンソールがわかりやすいし、Swing ベースの起動、終了ツールや、デプロイツールが付属してて好印象です。とっつきやすい感じがしました。

　JRun のドキュメントには、XDoclet の記述があります。XDoclet は JRun 4 に対応してます。今回のテストプログラムは、XDoclet を使って作りましたが、このツールはよくできたツールだと思います。Bean のソースを１つかけば、あとは自動生成ですから管理が楽です。今回、WebLogic と JBoss で検証したわけですが、ソースに、それぞれのベンダータグコメントを埋め込むだけで２つのアプリケーションサーバー対応することが可能です。もし、JRun に対応したければ JRun のベンダータグを埋め込めばＯＫです。ベンダータグの情報から、ベンダー独自の配備記述子が生成されるわけですが、そもそも、ベンダー独自の配備記述子が何をやってるかと言いますと、ejb-jar.xml で定義された論理的な定義と、実環境における JNDI 名の対応や、データベースとの対応、リレーション関係の外部キー等を記述しているわけです。ですから、最低必要な情報というのは各ベンダーともほぼ同じでして、配備記述子を格納するファイル名や書き方が違うだけなんですよね。プラスアルファとして、本当にベンダー固有な特徴的な設定が一部あるわけです。ですから、XDoclet を使うには、各ベンダー独自の配備記述子についての知識が必須というわけではありません。しかし、知っていないとどのタグをどのように埋め込むべきかがわからないこともあります。まあ、JBoss の場合はドキュメントがなかったにもかかわらず、なんとかなったわけですから、「気合いの問題」（爆）とも言えますが。。。最近 WebLogic 7.0 がリリースされましたが、これには EJBGen という XDoclet に似たツールが付属しているようです。考え方は XDoclet と同じです。

　例によって話が飛んでしまいましたが、JBoss については、今後も追いかけてみようと思います。ドキュメントも購入してみようかと思い出した今日この頃。。。

JBoss CMR 不具合 (2002/06/21)

　JBoss 3.0 をここ数日、色々と触ってました。そして CMR で動かないケースが存在することを確認しました。N:1 のリレーションシップで、Forignkey が更新されないという不具合です。前回は、1:N の関係で、1 の Student と、N の Book 複数を create するというテストを実施ました。今回確認したのは、リレーションシップとしては、同じ一対多ですが、主体が逆のケースです。具体的には以下のとおりです。

　会員を表す Account と、国を表す Country の２つの Bean において、会員は、居住する国を「国コード」として持ちます。この「国コード」は、Country の「国コード」と結びつきます。「会員：国＝多：１」の関係となります。ただ、１人の会員から見ますと１つの国に対応していることになります。

Account Entity Bean のリレーションシップは以下のようになります。

public abstract CountryLocal getCountry();
public abstract void setCountry(CountryLocal pCountry);

実際に関連づけを実施するコードは、

public void assignCountry(CountryData pData)
              throws ServiceUnavailableException,
                     InvalidValueException
{
    try {
        InitialContext lContext = new InitialContext();
        // ローカルホームを取得する
        CountryLocalHome lHome = (CountryLocalHome)PortableRemoteObject.narrow(
            lContext.lookup("java:comp/env/ejb/CountryLocal"),
            CountryLocalHome.class);
        // 既に Country に登録されているかどうか検索する
        CountryLocal lBean = lHome.findByPrimaryKey(new CountryPK(pData.getCountryId()));
        // 既に登録されているならば、既存の Country を関連づける
        setCountry(lBean);
    }
    catch ( FinderException fe ) {
        // Country に未登録ならば、新規登録して関連づける
        assignNewCountry(pData);
    }
    catch ( NamingException ne ) {
        throw new ServiceUnavailableException( "Naming lookup failure: " + ne.getMessage() );
    }
}

のようなコードです。Country に対応する「国名テーブル」に、いくつかのデータを登録した上で、Account を create し、assignCountry() で「国名テーブル」に登録済みの「国コード」を登録してみました。しかし、setCountry() がうまく動いてくれませんでした。特にエラーは発生しませんでしたが、Account に対応する「会員テーブル」の「国コード」は null のままとなり、どうしても更新されません。setCountry() した後に getCountry() をしてみると、正しいデータが返ってきましたので、テーブルに書き込まないという不具合だと思います。そこで試しに JBoss 3.1.0alpha を CVS から GET して動かしてみたところ見事に動きました。JBoss 3.0 の CMR （CMP 2.0 全般も？) は、まだ怪しい所がありそうですね。

　JBoss 3.0 には、他にもおかしな点があります。それは、EJB-QL です。例えば、「指定した国に居住している会員を抽出する」という EJB-QL は、

SELECT OBJECT(a) FROM Account AS a, IN (a.country) AS c WHERE c.id = ?1

となります。JBoss 3.0 は、この EJB-QL をパースできずにエラーとなってしまいます。JBoss では、これを、

SELECT OBJECT(a) FROM Account AS a WHERE a.country.id = ?1

と書かなければならないようです。しかし、EJB-QL は、J2EE の仕様で定義されいる部分ですから、JBoss 固有の仕様というわけにはいきません。少なくとも標準の記述が受け入れられないのは問題だと思います。

　ところで、sorceforge.net から JBoss 3.1.0alpha を GET したわけですが、3.0 系のバグフィックスって進んでいるでしょうかね。実は、Get して build したら、3.1.0alpha だったので驚いたのです。てっきり、3.0.x になるものだと思っていたからです。JBoss の開発体制を知る由もありませんが、新機能の実装、機能の改善、バグフィックスのバランスがどのようになっているのか気になるところです。JBoss 3.0 は EJB 2.0 に対応していることが売りですが、今回のように単純なケースでかつ、一般的によくあるケースにおいて不具合が見つかると、がっかりしてしまいます。JBoss のテストケースを見ても、リレーションシップのテストは、テーブルマッピングによる 1:1、1:N、M:N のケースがまとまって存在するだけです。論理的には、テーブルマッピングが必要なのは M:N の場合のみであり、1:1、1:N の場合に、わざわざテーブルマッピングを使う人はいないと思います。普通の forignkey マッピングのテストが不足しているのでしょう。また、一部、仕様に準拠していないのも気になるところです。J2EE 1.3 が FIX しているわけですから、仕様を満たしているかどうか詳細に検証するべきですね。こういった品質管理ができないまま勢いだけで進むと、どこぞの MS とかいう会社の製品と同じ道を辿ってしまわないかと心配です。

JBoss Jetty の憂鬱 (2002/06/26)

　JBoss のセキュリティについて調べようとして、Jetty でつまづきました。認証がうまく動かないんです。「j_security_check」を使った単純なFORM認証を試したのですがダメでした。

  <form method="post" name="Login" action="j_security_check">
    Username:<input type="text" name="j_username"/><br />
    Passward:<input type="password" name="j_password"><br />
    <input type="submit" value="Login" name="Submit" />
  </form>

という、Servlet に対する標準の認証呼び出しです。web.xml は、

  <welcome-file-list>
    <welcome-file>index.jsp</welcome-file>
  </welcome-file-list>

  <security-constraint>
    <web-resource-collection>
      <web-resource-name>Welcome</web-resource-name>
      <url-pattern>*.jsp</url-pattern>
    </web-resource-collection>
    <auth-constraint>
      <role-name>app_user</role-name>
    </auth-constraint>
  </security-constraint>

  <login-config>
    <auth-method>FORM</auth-method>
    <form-login-config>
        <form-login-page>/login.jsp</form-login-page>
        <form-error-page>/loginError.jsp</form-error-page>
    </form-login-config>
  </login-config>

  <security-role>
    <role-name>app_user</role-name>
  </security-role>

です。認証成功の場合は、welcome-file-list で指定した index.jsp を呼び出し、エラーの場合は、loginError.jsp を呼び出すという、いたって単純なテストです。JBoss 側のセキュリティは、とりあえず、users.properties というユーザー名とパスワードを記述したファイルと、 roles.properties というユーザー名とロール名を記述したファイルを %JBOSS_DIST%/server/default/conf に用意してやればＯＫです。JBoss は、デフォルトでは、org.jboss.security.auth.spi.UsersRolesLoginModule を使う設定になってます。そして、このログインモジュールが、users.properties, roles.properties を使用します。

users.properties

user=password

roles.properties

user=app_user

　これで普通に動くはずなのですが、Jetty ではうまく動いてくれませんでした。原因を追及するよりも使い慣れた Tomcat を組み込んで試してみましたら、あっさり動いてしまいましたので、へたれな私は、これ以上の追求を止めました。（笑）どうして JBoss はデフォルトのサーブレットエンジンに Jetty を選択したんでしょうね。Jetty よりも Tomcat のほうが広く使われているので、何かと安心できるのですが。。。ところで、JBoss 3.0 は、Tomcat 4.0.3 をバンドルしたバイナリが配布されています。しかし、私は CVS から GET した JBoss 3.1.0alpha のソースツリーと、Tomcat 4.0.3 から build して組み込みました。やり方はソースツリーの catalina ディレクトリ内の Readme に書いてありました。何故わざわざそうしたかと言いますと、先日発覚した CMR の問題で 3.1.0alpha を使っていたからです。

　さて、これで一応動きましたので Servlet と JBoss のログイン認証が連携できたことになります。ただ、多数のユーザーを管理するのに、テキストファイルを使うというのは非現実的です。ユーザー名、パスワード、ロールをデータベース管理するというのは通常よく行われている方法です。その他、最近は ldap と連携する方法もよくみかけられます。そして JBoss は標準でどちらにも対応してます。今回試したのは、データベースで管理する方法です。使用するログインモジュールは、org.jboss.security.auth.spi.DatabaseServerLoginModule という JBoss が標準で提供しているものです。まず、login-config.xml に、DatabaseServerLoginModule を使ったセキュリティドメインの設定を書きます。

    <application-policy name = "MyAppRealm">
      <authentication>
        <login-module code = "org.jboss.security.auth.spi.DatabaseServerLoginModule" flag = "required">
          <module-option name="dsJndiName">java:/OracleDS</module-option>
          <module-option name="principalsQuery">
            select u_password from Users where u_name=?
          </module-option>
          <module-option name="rolesQuery">
            select u_roles, u_rolegroup from UserRoles where u_name=?
          </module-option>
        </login-module>
      </authentication>
    </application-policy>

application-policy の name 属性で MyAppRealm というセキュリティドメイン名を定義してます。 login-module で、先ほどの DatabaseServerLoginModule を使うことを指定してます。各 module-option は、このログインモジュールで必要なパラメータです。dsJndiName は、データベース接続のための JNDI 名です。通常は java:/DefaultDS ですが、私は、Oracle を使ってまして、%JBOSS_DIST%server/default/deploy/oracle-service.xml に OracleDS を定義して接続しています。principalsQuery には、ユーザー名とパスワードを格納したテーブルから、ユーザー名を元にパスワードを抽出するSQLを記述します。rolesQuery には、ユーザー名、ロール名、ロールグループ名を格納したテーブルから、ユーザー名を元に、ロール名、ロールグループ名を抽出するSQLを記述します。当然、接続先のデータベースに該当するテーブルを２つ作成し、ユーザー名、パスワード、ロール名を登録しておく必要があります。テーブルの作成方法は、、、、create 文で作成して、 insert 文でデータを登録してください。（爆）

　次に、jboss-web.xml に、使用するセキュリティドメインを設定する必要があります。UsersRolesLoginModule を使った認証の場合は、特に何も記述しなかったのですが、何も書かない場合は「other」が使用されるようです。login-config.xml の下のほうに、<application-policy name=”other”> として UsersRolesLoginModule の設定が記述されています。今回は、MyAppRealm を定義しましたので、これを使用するために、jboss-web.xml に

   <security-domain>java:/jaas/MyAppRealm</security-domain>

を追加します。これで、servlet のログイン認証は、JBoss の MyAppRealm を使って認証できるようになります。JAAS というキーワードが光ってますね。（笑）と気づく方は、なかなか通と言えます。

　最後に、JBoss 側のセキュリティは、セキュリティドメインによるコンテナ単位の制限（jboss.xml に記述）や、ロール名による EJB 単位の制限（ejb-jar.xml に記述）ができます。ejb-jar.xml の EJB へのセキュリティ記述は、ロールに対する形で普通に書けばよいので特に述べる必要はないかと思います。JBoss のコンテナをセキュリティドメインに含める方法について若干触れますと、例えば、「セッション Bean のコンテナを MyAppRealm のセキュリティドメインで実行する」と定義することができます。この時、MyAppRealm に対する権限を持つユーザー（ロール）のみがセッション Bean を実行することができるわけです。

　以上、あまりつっこんだ検証はできませんでした。（反省）ログインモジュールの使い方ぐらいはわかるかなという程度ですね。JBoss を使ったシステム構築には、この程度わかれば十分だと思いますが。。。

JBoss 3.0.1RC1 (2002/07/02)

　JBoss 3.0.1RC1 がリリースされました。CVS から GET できる開発バージョンが、3.1.0alpha だったので、「どうなってんだ？」と思ってましたが、開発バージョンとリリースバージョンとは管理が違うみたいですね。ちょっと安心しました。3.0 からの変更点はリリースノートを見てもらうことにして、今まで私が見つけた、問題点がクリアされているかどうかを調べました。

CMR の Forignkey が更新されない問題直りました。問題なく更新できるようになりました。ただ、前のバージョンもそうでしたが、CMR の操作にはローカルインターフェースを使うのがコツでして、リモートインターフェースを使うと何故か動きません。WebLogic ではリモートインターフェースを使っても正常に動くのですがねえ。ただ、CMR フィールドについては、ローカルインターフェースを使ってやるのがベターだとは思います。
一部 EJB-QL を解釈できない問題まだダメです。解析できないようですね。私が間違っているんでしょうか？エラーメッセージを見る限り、IN を使った構文を理解できてないように思うのですが。。。
Jetty で認証が機能しない問題条件付きで動きました。たぶん前のバージョンでも動いていたのかもしれません。しかし、私が理解している（考えている） Servlet 仕様と動作が違います。ブラウザから、Web アプリケーションのベースURL を指定した時、Tomcat の実装では、welcome-file に指定したページを表示しようとしますが、そのページが認証を必要とする場合は、login-config に指定した認証が機能します。しかし、Jetty は、そのように動きません。Jetty は、単に welcome-file で指定したページを無条件に表示するようです。試しに、ログイン認証ページをちゃんと指定してやれば、認証後に welcome-file のページが表示されて動作しました。Tomcat の実装が正しいと思いたいのですが自信がありません。それとも、これは実装依存なんでしょうか？

ということで、JBoss は、日々進化しているようなので正式リリースに期待してます。あと、3.0 対応のマニュアルが早く整備されることを願ってます。現在無償で手に入るまとまったものは、Quick Start Guide だけですが、フリーのマニュアルが近日中に出る予定みたいので期待してます。