Geronimoの中でTomcatの力を解き放つ

ページオプション JavaScript を要するドキュメントオプションは表示されません サンプルコード 原文はこちら

レベル: 初級

Sing Li (westmakaha@yahoo.com), Author, Wrox Press

2005年 6月 14日

Geronimoには、2つの独立したWeb階層エンジン、JettyとTomcatが標準で組み込まれています。Geronimoを箱から取り出した状態では、Jettyが動作するようになっています。この記事ではTomcatのベテラン・ユーザーであるSingLiが、GeronimoをTomcat用にコンフィギュレーションしなおす方法を解説します。Tomcatおなじみの基本機能をGeronimoで利用するにはどうすべきか、そして、それらの機能を強化する方法を学びましょう。

Apache JakartaのTomcatは長年、最新のサーブレット仕様やJSP仕様に関する基準コンテナー実装でした。有名なオープンソースとして誕生以来、一貫して、世界中で実稼働品質のWeb階層エンジンとして採用されており、またApacheWebサーバーやMicrosoft® IISなど、業界標準のWebサーバーと組み合わせて使われています。喜ばしいことに、最新バージョンのTomcat5が標準でGeronimoに同梱されており、すぐに使えるようになっているのです。

ただし、TomcatはGeronimoの一部として統合されていますが、現在のアーキテクチャーではJettyとTomcatの両方で同時にWeb階層を処理できるようになっていません。デフォルトのJSP/サーブレット・エンジンはJettyとなっており、Jettyの代わりにTomcatをアクティブにするためには、コンフィギュレーションの変更を行う必要があります。

この記事では、Geronimo内にあるTomcatサーバーをイネーブルにし、コンフィギュレーションする方法を解説します。そして、Geronimoの持つコンポーネント化アーキテクチャーのおかげで、Tomcatとの統合が簡単にできること、またサンプルのWebアプリケーションをTomcatにデプロイするための実際について学びます。そして最後に大事なこととして、Geronimo/Tomcatの統合を利用して、Geronimoのコンテナー・ベースJAAS（Java™Authentication and Authorization Service）サポートを利用するJAASセキュリティー・レルム（securityrealm）をサンプル・アプリケーションに追加します。

Geronimoのアーキテクチャーを再検証する

Tomcatは代替のWeb階層コンテナーとして、Geronimoの中に統合されています。TomcatとGeronimoとがどのように統合されているかを理解するには、Geronimoの、GBeansベース・アーキテクチャーを少し思い出す必要があります。このアーキテクチャーの背景を学ぶには、「Geronimo! Part I: The J2EE 1.4 engine that could」（developerWorks, 2005年5月）を読んでください。

Geronimoコンテナーは、GBeansと呼ばれるソフトウェア・コンポーネントの、ライフサイクルとランタイム対話動作の管理を補助します。Geronimoカーネルは実行時に、『コンフィギュレーション』として知られる、事前構築されたGBeans群に命を吹き込みます（コンフィギュレーションについては、囲み記事、Geronimo GBeansとコンフィギュレーションを見てください）。コンフィギュレーションは、デプロイメント・プロセスの期間中に構築されます。概念的に言うと、デプロイヤーが、GBeansに対するバイナリー・コード（コード・モジュールという形です）とメタデータ情報（XMLデプロイメント・プランという形です）から、これらを処理してコンフィギュレーションのシリアル化イメージを作ります。このコンフィギュレーション・イメージはそのままコンフィギュレーション・ストアになります。このコンフィギュレーションが起動すると、カーネルはこのイメージをデシリアライズ（deserialize）します。

図1は、デプロイ時にGeronimoコンフィギュレーションがどのように作られるか、また実行時にカーネルがこれをどのように起動するかを示しています。

Geronimo GBeansとコンフィギュレーション デプロイメントの期間中には、様々なGBeanコンポーネントの集まりがコンフィギュレーションの中にパッケージされています。Geronimoカーネルはコンフィギュレーションしか理解しません。コンフィギュレーションというのは、個々のコンポーネントを常時監視せずに済ますために実行すべき何か（例えばアプリケーションや様々なサービス、あるいは単なるJARファイルの集まり）です。システムには通常、密接に結合されたコンポーネントの集まりがあります（こうしたコンポーネントは後で疎結合となります）。コンフィギュレーションは通常、密に結合されたグループそれぞれに対して存在します。

図1を見ると、デプロイヤーは、専用の『ビルダー』コンポーネントを呼ぶことで動作していることが分かります。この、専用ビルダーの主な役割は、特定タイプのコード・モジュールのメタデータからGeronimoの作業コンフィギュレーションを作成するためのナレッジをカプセル化することです（例えばJ2EEEARビルダーは、エンタープライズ・アプリケーションのEARファイルの中に含まれているコード・モジュールとメタデータからGeronimoコンフィギュレーションを作成する方法を知っています）。

図2.は、Geronimoの専用ビルダーの動作を拡大して見たものです。

図2では、専用ビルダーは入力されるメタデータ（デプロイメント・プラン）を処理し、GBeans（コード・モジュール）を構成し、出力としてコンフィギュレーションを作成します。カーネルは、このコンフィギュレーションを追加処理したり追加コンフィギュレーションしたりする必要なく、起動することができます。

デプロイされているコード・モジュールのタイプにより、デプロイヤーは別々の専用ビルダーを呼びます。例えば入力されるWAR（WebApplications aRchive）ファイルを処理する場合、デプロイヤーはWebモジュール・ビルダーを呼びます。図1を見ると、ビルダーによっては、動作する際に追加のメタデータ（デプロイメント・プラン）を要求する場合もあることが分かります。

図1から、下記を導くことができます。

• Geronimoカーネル/コンポーネントはJ2EE専用ではなく、基本的にGBeansとコンフィギュレーションによって動作する（囲み記事、Geronimo GBeansとコンフィギュレーションを見てください）。
• Geronimo J2EEサーバーは、専用サービス・コンフィギュレーション（Web階層、ビジネス階層、eis階層）と、それらに関連した専用ビルダーの集まりにすぎない。
• GBeanコード・モジュールや専用ビルダー、それらの関連デプロイメント・プランなどを作成することによって、Geronimoに新しいコンフィギュレーションを追加することができる。

上記のうち最後のポイントが、TomcatとGeronimoの統合が単純にできる理由です。

上に戻る

Tomcat Webモジュール・ビルダーを統合する

GeronimoデプロイヤーによってWARファイルがデプロイされると、デプロイヤーはコンフィギュレーションを作成するための専用Webモジュール・ビルダーを探します。Geronimoデプロイヤーのデフォルト・コンフィギュレーションでは、ビルダーとしてJettyModuleBuilderが固定されています。Tomcatをアクティブにするための主な作業は、TomcatModuleBuilderを使うようにデプロイヤーを書き換えることです。図3は、この状況を示しています。

サーバー・コンフィギュレーションの変更には再ビルドが必要 java -jar server.jarを使ってサーバーを実行する場合、実際には、既にビルドされた固定のコンフィギュレーション・セットを起動して実行します。Geronimoでは、こうしたビルド済みのコンフィギュレーション・セットを『アセンブリー』呼びます。このアセンブリーを作ることが、Geronimoビルド・プロセスの最終ステップです。デプロイヤーのコンフィギュレーションとTomcatサーバーのコンフィギュレーションは、このアセンブリーの一部なので、例えばJettyをTomcatで置き換えるなどの変更は、アセンブリーを再度作らない限りできません。現状では、これはつまり、Tomcatに変更する前にソースコードをチェックアウトし、Geronimoビルド・プロセスを設定しなければならないことを意味します。将来のGeronimoディストリビューションでは、Tomcatが既にアクティブとなってビルドされたサーバー・アセンブリーが利用できるようになるはずです。

図3では、TomcatModuleBuilderが作成したコンフィギュレーションには、TomcatWebAppContextが埋め込みで含まれています。このコンテキストは、TomcatContainerが、その実行時にWebアプリケーションを起動するために使用します。

Geronimoデプロイヤーをコンフィギュレーションするには、次の2つのデプロイメント・プランを使います。

• j2ee-deployer-plan.xml
• j2ee-runtime-deployer-plan.xml

これらのデプロイメント・プランは、Geronimoソース・ツリーのmodules/assembly/target/plansディレクトリーに保存されています。これらのデプロイメント・プランの内部を見ると、Jettyに関する参照や依存関係を示す記述が山のようにあるので、これらをコメント化する必要があります。同時に、Tomcatに関する参照や依存関係はコメントとなっているので、これらを非コメント化して復活させる必要があります。この作業でJettyとTomcatとの切り替えが行われるので、十分慎重に行います。これらのプランを変更するためには、Geronimoのソースコードをチェックアウトする必要があることに注意してください。サーバーの再ビルド手順に関しては、囲み記事、サーバー・コンフィギュレーションの変更には再ビルドが必要を見てください。

上に戻る

Tomcatコンテナーのコンフィギュレーション

古典的なTomcatでのサーバー・コンフィギュレーション・ファイルは、server.xmlと呼ばれます。このファイルは通常、（Tomcatのインストール・ディレクトリーを$CATALINA_HOMEとすると）$CATALINA_HOME/confディレクトリーの下にあります。このコンフィギュレーション・ファイルには、Tomcatサーバーを構成するコンポーネントのネスティングを記述します。単純なserver.xmlの例をリスト1に示します。

                
<Server port="8005" shutdown="SHUTDOWN">
    <Service name="MyService">
        <Connector port="8090"/>
        <Engine name="MyEngine" defaultHost="localhost">
           <Host name="localhost" appBase="webapps"/>
        </Engine>
     </Service>
</Server>

リスト1では、ネストされたコンポーネント、Hostが、Engineコンテナー・コンポーネントの中に構成されています。最上位レベルのServiceコンポーネントは、Engineと、ポート8090で着信リクエストをリスンしているHTTPConnectorコンポーネントとで構成されています。これは最低限のTomcatコンフィギュレーションとして典型的なものです。

server.xmlをj2ee-server-tomcat.xmlに変換する

GeronimoのTomcatコンフィギュレーション・モジュールは、大部分のTomcatコンポーネントに対してラッパーGBeansを作ります。その結果、（上記の）server.xmlは、GBeanベース・コンポーネントのつなぎ方を指示するデプロイメント・プランに変換されます。これは、j2ee-server-tomcat.xmlサーバーのデプロイメント・プランの一部として行われます。これをリスト2に示します。

                
<gbean name="MyTomcatContainer" class="org.apache.geronimo.tomcat.TomcatContainer">
    <attribute name="catalinaHome">var/catalina</attribute>
    <reference name="engineGBean">
        <name>TomcatEngine</name>
    </reference>
    <reference name="ServerInfo">
        <module>org/apache/geronimo/System</module>
        <name>ServerInfo</name>
    </reference>
</gbean>

<gbean name="TomcatWebConnector" class="org.apache.geronimo.tomcat.ConnectorGBean">
    <attribute name="initParams">
        port=8090
    </attribute>
    <reference name="TomcatContainer">
        <name>MyTomcatContainer</name>
    </reference>
</gbean>

<gbean name="TomcatEngine" class="org.apache.geronimo.tomcat.EngineGBean">
    <attribute name="className">org.apache.geronimo.tomcat.TomcatEngine</attribute>
    <attribute name="initParams">
        name=MyEngine
        defaultHost=localhost
    </attribute>
</gbean>

<gbean name="TomcatHost" class="org.apache.geronimo.tomcat.HostGBean">
    <attribute name="className">org.apache.catalina.core.StandardHost</attribute>
    <attribute name="initParams">
        name=localhost
        appBase=
        workDir=work
    </attribute>
    <reference name="engineGBean">
        <name>TomcatEngine</name>
    </reference>
</gbean>

j2ee-server-tomcat.xmlファイルを調べてみると、Tomcatサーバーのデフォルト・コンフィギュレーションが分かります。このプランは、Geronimoソース・ツリーのmodules/assembly/target/plansディレクトリーの中にあります。

server.xml には、ネストされた、他のTomcatコンポーネント（例えばrealmやvalve）が現れることがよくあります。これらのコンポーネントも、同じようにデプロイメント・プランの中につなぎ込むことができます。この先で説明する、GeronimoJAASレルムを使って、アプリケーション、『Really Big Pet Store』をセキュアーにするのセクションでは、TomcatエンジンにJAASレルムを追加する方法を説明しています。

Tomcatサーバー・コンポーネント階層構造のランタイム接続

図4は、J2EEサーバー・アセンブリーの一部として実行するTomcatContainerコンフィギュレーションをビルドするためにj2ee-server-tomcat.xmlデプロイメント・プランを使っている様子を示しています。

図4では、GBeansの接続命令（リスト2のものと似ています）を使ってTomcatサーバー（org/apache/geronimo/Tomcat）のコンフィギュレーションを作っています。このコンフィギュレーションができると、Geronimoカーネルによって、実行中にTomcatコンポーネントの階層構造が作られます（図の右側に示してあります）。

以上を要約すると、Jettyの代わりにTomcatをイネーブルにするためには、次のような手順に従います。

1. Geronimoソースコードをダウンロードしてインストールする。
2. MavenとSubversionをインストールする（これらのツールはソースコードをビルドするために必要です。参考文献を見てください）。
3. 上で説明したように、j2ee-deployer-plan.xmlファイルとj2ee-runtime-deployer-plan.xmlファイル、j2ee-server-tomcat.xmlファイルを変更する。
4. Mavenを使って、カスタムのTomcatアセンブリーを作る（これは、Geronimoソース・ツリーのmodules/assemblyディレクトリーの中でMavenを呼び出すことで行います）。
5. サーバーを起動し、java.endorsed.dirシステム・プロパティー（つまり、java-Djava.endorsed.dir=lib/endorsed -jar bin/server.jar）を設定したことを確認する。これが必要な理由は、現在のGeronimoリリースではJDK1.4 JVMが必要であり、Tomcatで必要なXML処理ライブラリーがデフォルトでは含まれていないためです。
6. Tomcatサーバー・コンフィギュレーションがまだ起動していなければ、ランタイム・デプロイヤーを使って起動する（つまりjava-jar bin/deployer.jar deploy org/apache/geronimo/Tomcatを実行する）。

将来、事前コンフィギュレーションされたTomcatアセンブリーがGeronimoと一緒にリリースされる可能性に関しては、囲み記事、サーバー・コンフィギュレーションの変更には再ビルドが必要が必要を見てください。

Tomcatアプリケーション・デプロイメント記述子とデプロイメント・プラン

TomcatをアクティブにしてGeronimoを起動すると、EARファイルやWARファイルのデプロイを開始でき、また、Web階層アプリケーション・コンポーネント（JSPやサーブレットなど）がTomcatでホストできるようになります。

図5は、TomcatにデプロイされるWebアプリケーションに対するデプロイメント記述子とデプロイメント・プランを示しています。

図5では、web.xmlという標準的なJ2EEデプロイメント記述子が、デプロイされたWARファイルの中に置かれています。TomcatModuleBuilderは、Webモジュールのコンフィギュレーションが作られる間に、この記述子を処理します。geronimo-tomcat.xmlファイルはGeronimo専用のデプロイメント・プランであり、WARファイルの中に含まれていることもあり、あるいは図5のように、デプロイメントが行われる間に提供されることもあります。このデプロイメント・プランは、Webアプリケーション用のコンテキストを作るためにTomcatModuleBuilderが処理します。古典的なバージョンのTomcatとは異なり、すべてのアプリケーションを保持するための、デフォルトのwebappsディレクトリーはありません。各Webアプリケーションは、それぞれ独自の独立なコンテキストで実行します。geronimo-tomcat.xmlプランについては、後の方で説明します。

表1を見ると分かるように、Webアプリケーションをデプロイする際にgeronimo-tomcat.xmlデプロイメント・プランを含めないと、Geronimoはデフォルト・プランを使います。このデフォルト・プランによって、web.xmlで規定されたアプリケーション名を持つ、あるいは（もしアプリケーション名がweb.xmlで規定されていない場合には）WARファイルのベース名を持つ、Tomcatルート・コンテキストが作られます。

上に戻る

サンプル・アプリケーションをデプロイする

このサンプルでは、以前の記事、「Geronimo! Part 2: Tame this J2EE 1.4 bronco」（developerWorks,2005年5月）の中で使用したコードを使用します。war_only/distディレクトリーの中にあるreallybigpet.warはWebアプリケーションであり、下記を含んでいます。

• JSP
• サーブレット
• JSTLライブラリー
• カスタム・タグ・ライブラリー

このWebアプリケーションをTomcatにデプロイするには、まず、Tomcatのコンフィギュレーションが起動していることを確認します。

java -jar bin/deployer.jar start org/apache/geronimo/Tomcat

入力を促されたら、ユーザー名としてsystemを、パスワードとしてmanagerを入力します。次にreallybigpet.warファイルをデプロイします。

java -jar bin/deployer.jar deploy reallybigpet.war

このWARファイルは、中にweb.xmlデプロイメント記述子を含んでおり、カスタムのgeronimo-tomcat.xmlデプロイメント・プランを使わずにデプロイされます。このデプロイメントには、TomcatModuleBuilderが作るデフォルトのプランで充分です。

デプロイされたアプリケーション、『Really Big Pet Store』をテストするには、ブラウザーを使ってURL、http://localhost:8090/reallybigpet/store.cgiにアクセスします。

ビルダーは、reallybigpetという名前のコンテキストを持つデプロイメント・プランを作ります。このコンテキスト名は、WARファイルの名前を元にしています。

Geronimo JAASレルムを使って、アプリケーション、『Really Big Pet Store』をセキュアーにする

TomcatはGeronimo内で、Geronimoによるコンテナー・ベースのJAASサポートを利用してセキュリティー・レルムを実装します。デフォルトのj2ee-tomcat-server.xmlコンフィギュレーション・ファイルを見てみると、TomcatJAASレルムがエンジン・レベルでコンフィギュレーションされていることが分かります（リスト3）。この、エンジンが参照しているJAASレルムは太字で示してあります。

                
<gbean name="TomcatEngine" class="org.apache.geronimo.tomcat.EngineGBean">
        <attribute name="className">org.apache.geronimo.tomcat.TomcatEngine</attribute>
        <attribute name="initParams">
            name=Geronimo
            defaultHost=localhost
        </attribute>
        <reference name="realmGBean">
            <name>TomcatJAASRealm</name>
        </reference>
    </gbean>

    <gbean name="TomcatJAASRealm" class="org.apache.geronimo.tomcat.RealmGBean">
        <attribute name="className">
          org.apache.geronimo.tomcat.realm.TomcatJAASRealm</attribute>
        <attribute name="initParams">
userClassNames=org.apache.geronimo.security.realm.providers.GeronimoUserPrincipal
 roleClassNames=org.apache.geronimo.security.realm.providers.GeronimoGroupPrincipal
        </attribute>
    </gbean>

このレルムを使って『Really Big Pet Store』をセキュアーにするには、web.xmlに<security-constraint>要素を追加する必要があります。サンプル・コードのwar_realm/ddディレクトリーを見ると、セキュリティー・コードを含んだweb.xmlファイルがあります。このweb.xmlファイルをリスト4に示します。セキュリティー・コードはハイライトしてあります。

                
<?xml version="1.0" encoding="ISO-8859-1"?>

<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee 
    http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
    version="2.4">

    <description>
   developerWorks Really Big Pet Store Example - for Geronimo
    </description>
    <display-name>IBM developerWorks Really Big Pet Store Example for Geronimo</display-name>

   <servlet>
      <servlet-name>ReallyBigPetStore</servlet-name>
      <servlet-class>com.ibm.dw.reallybigpet.StoreController</servlet-class>
   </servlet>
   <servlet-mapping>
     <servlet-name>ReallyBigPetStore</servlet-name>
     <url-pattern>/store.cgi</url-pattern>
   </servlet-mapping>
   <security-constraint>
      <display-name>Pet Store Security Constraint</display-name>
      <web-resource-collection>
         <web-resource-name>Entire store</web-resource-name>
           <url-pattern>/*</url-pattern>
         </web-resource-collection>
      <auth-constraint>
         <role-name>admin</role-name>
      </auth-constraint>
    </security-constraint>
    <login-config>
      <auth-method>BASIC</auth-method>
      <realm-name>Pet Store Login</realm-name>
    </login-config>
  <security-role>
      <role-name>admin</role-name>
    </security-role>
</web-app>

リスト4でハイライトされたコードは、Webアプリケーションへのアクセスを許す前に、GeronimoコンテナーによるデフォルトのJAASプロバイダーに対してユーザーを認証します。認証されたユーザーは、adminと呼ばれるロール/グループの中にいる必要があります。このデフォルト・プロバイダーは、var/securityディレクトリーの下にある一連のプロパティー・ファイルを使用します。デフォルトでは、adminと呼ばれる1つのグループだけが定義されています。このグループには1人のユーザーしかおらず、そのユーザー名はsystemであり、パスワードはmanagerです。

この、セキュアーになったバージョンのWebアプリケーションは、petsecure.warという名前でwar_realm/distディレクトリーの中にあります。これを、下記を使ってTomcatにデプロイします。

java -jar bin/deployer.jar deploy petsecure.war

このWebアプリケーションにアクセスするには、http://localhost:8090/petsecure/store.cgiというURLを使います。

今度は、認証用のログイン・ダイアログが表示されます。ユーザー名としてsystem、パスワードにmanagerを使って、店（ReallyBig Pet Store）にアクセスします。

カスタムのデプロイメント・プランを使ってWebアプリケーションをTomcatにデプロイする

ここまでは、私達のアプリケーションを両方とも、カスタムのgeronimo-tomcat.xmlデプロイメント・プランを使わずにデプロイしました。最後の例では、カスタムのプランを使ってreallybigstore.warをデプロイします。

カスタムのデプロイメント・プランがある場所は、ダウンロードできるソース（参考文献）の、custom_planディレクトリーです。このプランはcustplan.xmlと呼ばれ、コンフィギュレーション名をorg/apache/geronimo/BigPetStoreに設定し、アプリケーションに対するコンテキスト名を/Shoppingに設定します。

                
<web-app
    xmlns="http://geronimo.apache.org/xml/ns/web/tomcat"
    xmlns:sec="http://geronimo.apache.org/xml/ns/security"
    configId="org/apache/geronimo/BigPetStore">
    <context-root>/Shopping</context-root>
    <context-priority-classloader>false</context-priority-classloader>
</web-app>

このアプリケーションを再度デプロイする前に、先ほどまでのサンプル・アプリケーションを必ずアンデプロイします。

カスタム・プランを持つWebアプリケーションを、下記のようにデプロイします。

java -jar bin/deployer.jar deploy reallybigpet.war custplan.xml

デプロイが終わると、http://localhost:8090/Shopping/store.cgiというURLから、新しいコンテキストでアプリケーションにアクセスすることができます。

デプロイヤーのlist-modulesコマンドを使うと、デプロイされたorg/apache/geronimo/BigPetStoreのコンフィギュレーションを見ることができます。

                
java -jar bin/deployer.jar list-modules
Found 19 modules
    org/apache/geronimo/Tomcat
    org/apache/geronimo/ActiveMQServer
    org/apache/geronimo/J2EEDeployer
    org/apache/geronimo/DefaultDatabase
    org/apache/geronimo/SpringDeployer
    org/apache/geronimo/Secure
    org/apache/geronimo/DebugConsole
    org/apache/geronimo/Server
    org/apache/geronimo/DeployerSystem
    org/apache/geronimo/ClientSystem
    org/apache/geronimo/SystemDatabase
    org/apache/geronimo/Client
    org/apache/geronimo/SpringRuntime
    org/apache/geronimo/SystemJMS
    org/apache/geronimo/RuntimeDeployer
    geronimo-demo-1.0-SNAPSHOT
    org/apache/geronimo/System
    org/apache/geronimo/BigPetStore
    org/apache/geronimo/RemoteClassLoadingDeployer

上に戻る

まとめ

現在のGeronimoビルドにはTomcatエンジンが含まれていますが、これをアクティブにするためには、コンフィギュレーション・ファイルを手動で編集し、アセンブリーを再ビルドする必要があります。JSPやサーブレット、フィルター、タグ・ライブラリーなどを含むWebアプリケーションは、Tomcatコンテナーに対してデプロイし、実行することができます。Tomcat特有の機能、例えば仮想ホストやレルム、バルブなどが使用できる一方、Geronimoのサービス、つまりJAASやトランザクション、JNDI（JavaNaming and Directory Interface）などは完全に統合されています。GeronimoでTomcatを使うことによって、両者の良いところ、つまり管理可能でスケーラブルなオープンソースのJ2EEサーバーの最新機能と、豊富な機能を持つ、成熟したWeb階層コンテナーの堅牢さを、同時に利用できるのです。

上に戻る

謝辞

この記事の草稿に対して貴重なコメントを下さった、GeronimoチームにおけるTomcat統合の中心的開発者、JeffGenenderに心より感謝いたします。

上に戻る

ダウンロード

	ダウンロード形式について

参考文献

• Geronimoに関する2回シリーズの記事を読んでください。第1回「The J2EE 1.4 engine that could」はGeronimoの紹介と、その考え方の概要です。第2回「Tame this J2EE 1.4 bronco」は、Geronimoのコンフィギュレーションやデプロイメント、管理などを解説し、またWebアプリケーションとEJBの実際的なデプロイ手順を、例を挙げて説明しています。（developerWorks,2005年5月）
  
  
• Apache Geronimoに基づくオープンソースのアプリケーション・サーバーである、Gluecode Standard Editionをダウンロードしてください。
  
  
• Geronimo wiki には、Tomcatの統合と、デプロイメントの手順に関する最新情報が提供されています。
  
  
• Apache Jakarta Tomcatの正式Webサイトには、入手可能なTomcat 5サーバーの最新リリースに関する情報が提供されています。また、ここにはコンフィギュレーションに関する詳細なドキュメンテーションも用意されています。これらに関連したメーリング・リストを利用すれば、ユーザー・サポートを受けることができます。
  
  
• Geronimo projectの正式サイトには、最新のソースコードとバイナリーがあり、また、メーリング・リストやwikiによる活発なコミュニティーがあります。
  
  
• Jettyは、Geronimoに統合されているデフォルトのサーブレット/JSPコンテナーです。詳しい情報に関しては、Jettyの正式サイトを見てください。
  
  
• Geronimoでは、マルチプルジェクト・コードのビルド管理にはApache Mavenを使い、個々のプロジェクトのビルドにはApache Antを使っています。大部分のプロジェクトに対するバージョン・コントロールはSubversionを使って行われ、また幾つかのプロジェクトでは相変わらず CVS が使われています。
  
  
• developerWorks blogsに参加して、developerWorksのコミュニティーの一員になってください。
  
  
• developerWorksのOpen sourceゾーンには、Apacheに関する記事や無料のApacheチュートリアルが豊富に用意されています。
  
  
• Apacheに関する技術書とトピックスをご覧ください。
  
  
• developerWorksのGeronimo project areaには、無料のオープンソース・リソースの完全なリストが用意されていますので、ぜひ目を通してください。
  
  

著者について

		Sing LiはWrox Pressから出版されている多数の本の著者で、Professional Apache Tomcat 、Early Adopter JXTA 、Professional Jini などを執筆しています。技術雑誌に頻繁に寄稿しており、P2P発展に関する熱心なエバンジェリスト（伝道者）でもあります。コンサルタント兼ライターであるSingの連絡先はwestmakaha@yahoo.comです。

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

この記事を共有する はてなブックマーク livedoorクリップ del.icio.us Buzzurl（バザール） Choix！ Saafブックマーク FC2ブックマーク MM/memo ニフティクリップ Yahoo!ブックマーク CZブックマーク newsing

上に戻る