UIX開発者ガイド | ![]() 目次 |
![]() 前へ |
![]() 次へ |
「UIX開発者ガイド」の第I部で、UIXベースのアプリケーションの開発の基本について学習しました。ただし、必ず知っておく必要のある基本的なトピックがあります。アプリケーションのインストールおよびデプロイ方法です。UIXベースのアプリケーションのインストールは、他のWebアプリケーションのインストールと大きな違いはありません。このトピックでは、UIXの単純な「Hello, World!」アプリケーションのインストールを例にし、インストール・プロセスの手順を説明します。通常のアプリケーションは、この単純なサンプル・アプリケーションよりもさらに複雑ですが、インストールに必要な手順はほぼ同じです。
ここでは、次の項目について説明します。
インストール・プロセスを開始する前に、UIXで使用されるクラス・ライブラリ、テクノロジおよびリソースを理解する必要があります。UIX自体は、uix2-install.zipファイルを介して配布されるイメージ、スタイルシート、およびJavaScriptライブラリと、uix2.jarという1つのクラス・ライブラリで構成されます。
次の各セクションでは、UIXで必要な依存性すべてを説明します。このセクションで説明するクラス・ライブラリはすべて、オラクルの開発ツール・スィートであるOracle9iDSと、オラクルのアプリケーション・サーバー製品であるOarcle9iASの両方で配布されます。Java JDKなどのいくつかのコア・テクノロジは、他のソースから入手する必要があります。
UIXはJavaベースのテクノロジであるため、Java Runtime Environmentが必要です。特に、UIXでは、最低でもバージョン1.2(推奨は1.3.1、リリース済の場合は1.4)のJava 2 Platform Standard Editionが必要です。
Windows、Solaris、およびLinuxプラットフォームのJava 2 Runtime Environmentは、Sun社(http://java.sun.com/j2se/)からダウンロードできます。他のほとんどのプラットフォーム・ベンダーでは、オペレーティング・システムとともにJREを配布していますが、使用しているプラットフォーム・ベンダーのWebサイトにアクセスして、使用可能な最新バージョンを所有しているかを確認することをお薦めします。一般的に、Javaの最新バージョンは旧バージョンよりも動作が優れているため、使用しているJREオプションを調べることは有益です。(注意: java -version
コマンドで、実行しているJREのバージョンを調べることができます。)
UIXには、サーブレットAPIのバージョン2.0以上をサポートするサーブレット・エンジンが必要です。この要件はほとんどのサーブレット・エンジンで満たされているため、UIXベースのアプリケーションは任意のサーブレット・エンジンで実行できます。Oracleのアプリケーション・サーバーであるOracle9iASは、現在、2つのサーブレット・エンジンをサポートしています。
UIXは、Apache Tomcatサーブレット・エンジンの最新バージョンにおいてもテストされています。
サーブレットAPI自体は、Sun社によって定義されます。サーブレットAPIの詳細は、Sun社のJava Servlet Technologyサイト(http://java.sun.com/products/servlet/)を参照してください。
UIXでは、uiXML文書、XML Style Sheet Language(XSS)文書、およびUIX Dynamic Imagesのメタデータ文書を含む様々なXML文書タイプの解析に、XMLパーサーが必要です。UIXクライアントでは、Oracle XML Parser For Javaバージョン9を使用することをお薦めします。Oracle XML ParserのJARファイルであるxmlparserv2.jarは、Oracleのアプリケーション・サーバー(Oracle9iAS)および開発ツール(Oracle9iDS)の両方とともに出荷されます。最新のベータ版およびリリースなど、Oracle XML Parserの詳細は、Oracle Technology Network(http://otn.oracle.com/tech/xml/xdk_java/content.html)を参照してください。
Oracle XML ParserはUIXの推奨パーサーですが、UIXのXMLProvider
APIでは、ほとんど任意のXMLパーサーをプラグインできます。UIXには、Oracle XML ParserおよびApache Xercesパーサーの両方に対するXMLProvider
バインドが含まれています。使用するXMLパーサーに対するXMLProvider
バインドを開発できます。
UIXでは、XML解析にSAX 2 APIも必要となるので注意してください。SAX 2 APIは、イベントベースのXML解析の業界標準インタフェースです。ほとんどのXMLパーサーでは、すでにSAX 2 APIをサポートしています。SAX 1 APIをサポートするXMLパーサーで、SAX 2 APIをサポートしないものは、Meggison Technologies(http://www.megginson.com/SAX/)から提供されるSAX 2アダプタ・クラスを使用して、SAX 2 APIに適応できます。
UIXは、正規表現解析にApache Regexpパッケージを使用します。Apache Regexp JARファイルであるregexp.jarは、Oracle9iASおよびOracle9iDSの両方とともに出荷されます。このパッケージのドキュメントおよび最新バージョンは、Apache Regexpサイト(http://jakarta.apache.org/regexp/index.html)からも入手できます。
Shareパッケージは、様々なOracle製品およびテクノロジで使用されるユーティリティ・クラスのセットを提供します。ShareのJARファイルであるshare.jarは、Oracle9iASおよびOracle9iDSとともに配布されます。
UIX Dynamic Imagesのテクノロジにより、UIXページで使用するいくつかのイメージ(ボタンおよびタブ・バーなど)を、必要に応じて実行時に作成できます。UIX Dynamic Imagesでは、これらのイメージの作成にAWTグラフィック・ライブラリを使用します。Java 2バージョン1.4より前のAWTは、プラットフォーム固有のネイティブ・グラフィック機能を介して、その機能の大部分を実装しています。UNIX環境では、基本のグラフィック・レイヤーはX Window Systemを介して実装されます。X Window Systemはネットワークベースのグラフィック・システムで、グラフィック・リクエストが(ネットワーク越しに)Xサーバーに送信されます。Xサーバーでは、リクエストされたグラフィック操作を実行することにより、リクエストを処理します。
UIXベースのアプリケーションをUNIXプラットフォームにデプロイする場合は、追加の構成手順を実行します。UIXおよびAWTは、イメージ生成を正常に実行できるようXサーバーにアクセスできる必要があります。サーブレット・エンジンを起動する前に、DISPLAY環境をXサーバーの場所を指すよう設定してください。DISPLAY環境変数の設定は、通常は簡単なプロセスです。ただし、X Window Systemでは(ネットワーク・システムのため)様々なセキュリティ・メカニズムをサポートしているので、UIXのデプロイにおいて問題が生じる場合があります。
最悪のケースは、UIXがXサーバーにアクセスできない場合に、アプリケーションは稼働しますがイメージ生成は使用不可になることです。このような場合、UIXでは別のHTMLコンテンツ(たとえば、ボタン・イメージのかわりにテキスト・リンク)をレンダリングするため、外観が少し見劣りするものが生成されます。このような動作、またはX Window Systemやイメージ生成での問題に関連するエラー・メッセージに直面した場合は、「イメージ生成のためのXサーバー構成」のトピックを参照してください。
Xサーバー依存性および必要な構成処理は、まもなく不要になります。現在のベータ版のJava 2バージョン1.4に関しては、Javaはヘッドレス・オペレーションをサポートしており、Xサーバーなしでグラフィック操作を実行できます。当面の間は、他の解決方法を使用してXサーバー関連の問題をいくつか軽減できます。たとえば、イメージ・サーブレットを使用して、グラフィック操作により適した別のマシンにイメージ生成をオフロードできます。イメージ・サーブレットを使用し、イメージ生成をUNIX中間層マシンから専用のWindowsイメージ生成サーバーに移動して、Xサーバーの必要性を除去できます。解決方法の詳細は、「イメージ生成のためのXサーバー構成」のトピックを参照してください。
UIX Dynamic Imagesには、イメージ生成に必要な特定の要件がもう1つあります。テキスト・ラベル付きのボタンまたはタブなど、テキストベースのコンテンツがあるイメージを生成するには、AWTにUIXアプリケーションでサポートされる任意の言語に対するアクセスが必要です。すべての中間層環境が適切な国際化フォントで構成されているとはかぎらないため、Oracle9iASには、ほとんどの言語で使用できるTrue Typeフォントのセットが含まれています。これらのフォントは、ArialまたはHelveticaに類似した、sans-serifスタイルのAlbanyタイプ・フェイスを使用します。
Oracle9iASには、4種類のAlbanyフォントが含まれています。各フォントは(ほぼ)完全なUnicodeフォントであり、ほとんどの言語の絵文字が含まれています。4つのフォントの違いは、フォントのCJK統合漢字の部分で使用される絵文字です。フォントは次のとおりです。
AWTでこれらのフォントを使用可能にするには、これらをJavaのjre/lib/fontsディレクトリにコピー(またはリンク)する必要があります。AWTは、このディレクトリでTrueTypeフォントを自動的に検索し、検出したすべてのフォントをロードします。したがって、Webアプリケーションのインストール前に、これらの4つのフォント・ファイルがマシンのjre/lib/fontsディレクトリに存在するかを確認する必要があります。存在しない場合は、フォント・ファイルをこのディレクトリにコピーするか、このディレクトリからこれらのファイルへのシンボリック・リンクを作成し、イメージ生成中にフォントを使用できるようにしてください。
これらのフォントが検出されない場合、UIX Dynamic ImagesではかわりにDialogというAWT仮想フォントを使用し、AWTのfont.propertiesメカニズムでこのフォントをプラットフォーム固有のフォントにマップします。
イメージ生成で使用する特定のフォントがある場合は、blaf.xssで定義されるDefaultServerFontFamilyスタイルをオーバーライドすることで、そのフォントを使用するようUIX Dynamic Imagesを構成できます。変更方法の詳細は、「カスタマイズ」のトピックを参照してください。
このセクションでは、Oracle Containers For J2EE(OC4J)サーブレット・エンジンでUIXベースのアプリケーションをデプロイする手順を説明します。このトピックの目的から、次の単純なUIX文書、HelloWorld.uixを、アプリケーションとして使用します。
<?xml version="1.0" encoding="UTF-8"?>
<page xmlns="http://xmlns.oracle.com/uix/controller"
xmlns:ui="http://xmlns.oracle.com/uix/ui"
xmlns:ctrl="http://xmlns.oracle.com/uix/controller">
<content>
<pageLayout xmlns="http://xmlns.oracle.com/uix/ui">
<contents>
<header text="Hello, World!"/>
</contents>
</pageLayout>
</content>
</page>
このセクションの最後には、この文書をOC4Jサーブレット・エンジンで実行して表示できるようになります。
このセクションでは、ファイル・システムで個々のアプリケーション・ファイルに直接アクセスできる展開ディレクトリ構造または拡張ディレクトリ構造を使用した、サンプルUIXアプリケーションのデプロイ方法を示します。このデプロイ構成は、再パッケージせずにUIXファイルを簡単に変更およびテストできるため、開発プロセスで特に便利です。次のセクションで、同じ「Hello, World!」アプリケーションをEARファイル形式を使用してパッケージし、デプロイする方法を説明します。本番システムへのデプロイでは、この方法が適切です。
このセクションで説明する手順は、考えられるOC4J構成の中で最も単純なものです。したがって、ここでの手順は、開発中にUIX文書を実行する必要のある開発者を対象としています。実際のアプリケーションのデプロイでは、ロード・バランシングおよびEJBホスティングなど、より拡張したOC4J機能を利用することが多々あります。このドキュメントではこれらの拡張機能については触れませんが、OC4Jのドキュメント・セットで詳しく説明しています。OC4Jの詳細は、Oracle Technology Network(http://otn.oracle.co.jp/products/app_server/oc4j/oc4j)を参照してください。
OC4Jは、Oracle9iASアプリケーション・サーバーの標準コンポーネントです。Oracle9iASの最新バージョンがすでにインストールされている場合、OC4JはOracleホームのj2ee/homeディレクトリにあります。まだOracle9iASをインストールしていない場合は、Oracle Technology Network(http://otn.oracle.co.jp/products/app_server/oc4j/oc4j)からOC4Jを個別にダウンロードできます。OC4JのZIPファイル(oc4j.zip)をダウンロードした後で、次の手順を実行してOC4Jをインストールします。
OC4Jを任意のディレクトリに解凍します。j2ee/homeディレクトリの下にディレクトリ構造(j2ee/home/applications、j2ee/home/configなど)が作成されます。一部のバージョンのoc4j.zipファイルでは、実際には2つの別のZIPファイル、petstore.zipおよび2番目のoc4j.zipが含まれています。ZIPファイルにこの2つのファイルが含まれている場合は、2番目のoc4j.zipファイルを解凍し、OC4Jディレクトリ構造およびファイルを作成してください。
このコマンドは、コンソール・ウィンドウ(たとえば、DOSシェルまたはUNIX端末)から実行する必要があります。コンソール内で、カレント・ディレクトリをステップ1で作成したj2ee/homeディレクトリに変更し、次のコマンドを実行します。
java -jar oc4j.jar -install
プロンプトが表示された後、adminユーザーのパスワードを入力します。このパスワードは、後で管理タスクを実行する際に必要になります。(注意: 旧バージョンのOC4Jでは、oc4j.jarファイルはorion.jarという名前になっています。orion.jarファイルがある場合、必要に応じてoc4j.jarファイルと置き換える必要があります。)
j2ee/homeディレクトリから、次のコマンドを実行してOC4Jを開始します。
java -jar oc4j.jar
「Oracle9iAS (<your version>) Containers for J2EE initialized」など、OC4Jが開始したことを示す出力が表示されます。
OC4Jが正常に動作していることを確認するために、ブラウザからhttp://localhost:8888/にアクセスします。ブラウザのプロキシ構成設定によっては、OC4Jをホストするマシンの完全なドメイン名を指定する必要があります(たとえば、http://localhost.your.domain.com:8888)。インストールが正常に終了した場合は、ブラウザに「Oracle9iAS Containers for J2EE 1.0.2.2 - Up and running」などの初期画面メッセージが表示されます。
OC4Jを停止するには、j2ee/homeディレクトリから次のコマンドを実行します。
java -jar admin.jar ormi://localhost admin <your admin passord> -shutdown
各OC4Jインスタンスは、複数のJ2EEアプリケーションをホストします。J2EEアプリケーションは、任意の数のWebコンポーネント(サーブレットまたはJSP)と、任意の数のEJBコンポーネントから構成されます。UIXベースのWebアプリケーションを含め、任意のWebアプリケーションをデプロイするには、3つの手順を実行する必要があります。まず、J2EEアプリケーションを作成します。次に、Webアプリケーションを作成します。最後に、WebアプリケーションをOC4Jサーバー上の特定のURLにバインドし、Webブラウザを介してアクセスできるようにします。このセクションでは、このプロセスを、手動で設定する方法を説明します。
アプリケーションを手動作成する場合は、インストールが完了するまでOC4Jを停止しておくことをお薦めします。OC4Jでは構成ファイルに対する変更を動的に調べるため、部分的に編集された構成ファイルの解析において問題が生じる場合があります。
j2ee/home/applications/HelloWorldAppディレクトリを作成してください。
j2ee/home/configディレクトリのserver.xmlファイルには、<application>
要素が各J2EEアプリケーションに対して1つずつ含まれています。次のXML要素は、サンプルUIXアプリケーションにこの要素を指定する方法を示しています。
<application name="HelloWorldApp"
path="{your path}/j2ee/home/applications/HelloWorldApp"
auto-start="true"/>
server.xmlファイルで、この要素を<application-server>要素の子として<global-application>要素の直後に追加します。フルパスは、必ずインストールしたOC4Jへのフルパスに置き換えてください。
この手順では、新規Webアプリケーションを作成し、Webアプリケーションを構成するWebアプリケーション・コンポーネント(この例ではBajaServlet)を定義します。
これらのディレクトリを作成すると、ディレクトリ構造にはj2ee/home/applications/HelloWorldApp/HelloWorldWebAppというディレクトリが含まれます。
web.xml
ファイルをインストールします。
WEB-INFディレクトリに、次のようなweb.xml
ファイルを作成します。XMLプロローグ(<?xml version="1.0"?>
)の前に空白文字がないことを確認してください。この宣言の前に空白文字があると、一部のパーサーでは文書の解析に失敗します。
<?xml version="1.0"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/j2ee/dtds/web-app_2_3.dtd">
<web-app>
<servlet>
<servlet-name>uix</servlet-name>
<servlet-class>oracle.cabo.servlet.BajaServlet</servlet-class>
<init-param>
<param-name>oracle.cabo.servlet.pageBroker</param-name>
<param-value>oracle.cabo.servlet.xml.UIXPageBroker</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>uix</servlet-name>
<url-pattern>/uix/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>uix</servlet-name>
<url-pattern>*.uix</url-pattern>
</servlet-mapping>
<login-config>
<auth-method>BASIC</auth-method>
</login-config>
</web-app>
このディレクトリには、J2EEアプリケーションで使用するWebアプリケーションの名前など、J2EEアプリケーションのメタデータを定義するapplication.xml構成ファイルが含まれます。j2ee/home/applications/HelloWorldAppディレクトリの下に、META-INFディレクトリを作成してください。
application.xml構成ファイルの内容は、次のとおりです。
<?xml version="1.0"?>
<!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN" "http://java.sun.com/dtd/application_1_3.dtd">
<application>
<display-name>HelloWorldApp</display-name>
<module>
<web>
<web-uri>HelloWorldWebApp</web-uri>
<context-root>/</context-root>
</web>
</module>
</application>
この内容を、j2ee/home/applications/HelloWorldApp/META-INF/application.xmlというパスで新規application.xmlファイルに保存します。
ここでも、XMLプロローグの前に空白文字がないことを確認してください。
OC4Jを介してWebアプリケーションにアクセスするには、WebアプリケーションをURLにバインドする必要があります。
次の要素をj2ee/home/config/default-web-site.xml
ファイルの<web-site>
ルート要素の子として追加し、Webアプリケーションを手動でバインドします。
<web-app application="HelloWorldApp"
name="HelloWorldWebApp"
root="/greetings"/>
これで、J2EEアプリケーションおよびWebアプリケーションの作成が終了し、URLへのWebアプリケーションのバインドも行うことができました。
サンプルUIXアプリケーションは、1つのUIX文書で構成されています。この文書の内容を、前述の場所からj2ee/home/applications/HelloWorldApp/HelloWorldWebApp/ディレクトリのHelloWorld.uixファイルにコピーします。HelloWorld.uixファイルで、XMLプロローグの前に空白文字がないことを確認してください。
通常、アプリケーションは、次のような様々な種類のリソースで構成されます。
Webアプリケーションのルート・ディレクトリ(この例では、j2ee/home/applications/HelloWorldApp/HelloWorldWebApp
)は、Webアプリケーションのドキュメント・ルートとして機能するため、アプリケーション・ファイルのほとんどは、このディレクトリの下の適切なサブディレクトリにコピーする必要があります。
多くのアプリケーション・リソース・ファイルが使用されること以外に、通常のアプリケーションとサンプル・アプリケーションとの間には、通常のアプリケーションには(イベント・ハンドラ、データ・プロバイダなどの)Javaコードがいくつか含まれるという重要な違いがあります。アプリケーションで使用されるJARファイルを<web app>/WEB-INF/lib
ディレクトリに、JARファイルに含まれないクラスを<web app>/WEB-INF/classes
にコピーしてください。また、これらのクラスは、次の「クラスパスの設定」のセクションで説明する方法でクラスパスに追加することもできます。
UIX自体で、それ自身のイメージ、JSP、JavaScriptライブラリおよびスタイルシートを使用します。これらのファイルはuix2-install.zipで配布されます。UIXのインストール可能ファイルを、Webアプリケーションのルート・ディレクトリに解凍してください。次のディレクトリが作成されます。
j2ee/home/applications/HelloWorldApp/HelloWorldWebApp/cabo/images
j2ee/home/applications/HelloWorldApp/HelloWorldWebApp/cabo/jsps
j2ee/home/applications/HelloWorldApp/HelloWorldWebApp/cabo/jsLibs
j2ee/home/applications/HelloWorldApp/HelloWorldWebApp/cabo/styles
Webアプリケーションのルート・ディレクトリへのUIXリソースのインストールは、これまでのところ最も簡単に設定できる構成ですが、このアプローチにはいくつかの障害があります。特に、Webアプリケーションごとにこれらのファイルのコピーが必要になるため、Webアプリケーション数の多いOC4Jデプロイではリソースの浪費になります。この場合は、別のWebアプリケーション、または別のWebサーバーにデプロイされたUIXリソースの共通のセットを共有することが適切です。この問題および考えられる解決方法の詳細は、「UIXのインストール可能リソースの共有」のセクションで説明します。
UIXクラスは、uix2.jarという1つのJARファイルで配布されます。このファイルをクラスパスに追加する必要があります。UIXは、次のライブラリにも依存します。
これらのJARをそれぞれ、クラスパスに追加する必要があります。追加する方法の1つは、これらのファイルすべてをWebアプリケーションのWEB-INF/lib
ディレクトリにコピーすることです。このディレクトリにインストールされるライブラリは、Webアプリケーションに対してプライベートなものとして扱われます。つまり、これらのライブラリのクラスはアプリケーション固有のクラス・ローダーによってロードされ、同じサーブレット・エンジンで稼働する他のアプリケーションとは共有されません。
複数のアプリケーションで1つのライブラリ・コピーを共有することが適切な場合もあります。これらのライブラリをOC4Jインスタンスのすべてのアプリケーションで使用可能にするには、<library>
要素を使用して、各JARファイルへのパスをj2ee/home/config/server.xml
構成ファイルに追加してください。<library>
要素は、<application-server>
ルート要素の子として追加する必要があります。各ライブラリ要素で、JARファイルのファイル・システム・パスを指定する1つの属性、path
を定義します。
JARファイルの適切な親ディレクトリに置き換えた後で、次の行をserver.xml
構成ファイルに追加します。
<library path="{your path}/uix2.jar"/>
<library path="{your path}/xmlparserv2.jar"/>
<library path="{your path}/regexp.jar"/>
<library path="{your path}/share.jar"/>
これで、実行の準備が整いました。OC4Jを停止し、再起動してください。次のどちらかのURLを使用して、HelloWorld.uix
ページにアクセスできます。
http://localhost:8888/greetings/HelloWorld.uix
http://localhost:8888/greetings/uix/HelloWorld
ブラウザの設定によっては、マシンの完全なドメイン名(たとえば、http://localhost.your.domain.com:8888/greetings/HelloWorld.uix
など)を入力するように求められることがあります。
なんらかの原因で「Hello, World!」メッセージがブラウザに表示されない場合は、エラー・メッセージがないかコンソール・ウィンドウを確認してください。エラーはj2ee/home/application-deployments/HelloWorldApp/application.log
のアプリケーション固有エラー・ログ内に記録されるか、またはj2ee/home/log
のログ・ファイルの1つに記録されます。
UIXアプリケーションを展開Webアプリケーションとしてデプロイすることは開発目的では有用ですが、展開ファイル形式は本番環境には適切ではありません。これらの全ファイルをすべての中間層サーバーで保持することは、困難です。アプリケーションの配布およびデプロイには、EARファイルが便利です。EARファイルは、エンタープライズ・アプリケーション全体を含む単一のアーカイブで、Webアプリケーションとサポートする任意のEJBクラスの両方が含まれます。EARファイル形式はJ2EEプラットフォーム仕様で定義されるため、OC4Jを含む任意のJ2EE対応のコンテナで実行する必要があります。
このセクションでは、単純な「Hello, World!」アプリケーションのEARファイルを作成およびデプロイする方法を説明します。
EARファイルの準備および作成には多くの異なる方法があり、このプロセスを支援するツールも数多くありますが、わかりやすくするために手動で実行します。実際のEARファイル形式は、展開アプリケーション・デプロイに対してこれまでに作成したディレクトリ構造によく似ています。EARファイルを作成する前に、次のディレクトリ構造を作成する必要があります。
---- META-INF
| ---- application.xml
|
`---- HelloWorldWebApp
|---- HelloWorld.uix
|---- cabo/
| |---- images
| |---- jsLibs
| |---- jsps
| |---- styles
`---- WEB-INF/
|---- web.xml
`---- lib
|---- uix2.jar
|---- xmlparserv2.jar
|---- regexp.jar
`---- share.jar
この時点で、このディレクトリ構造を作成するために必要なファイルすべてについて理解している必要があります。次の手順に従って、必要なファイルをインストールします。
前述のサンプル・ファイルから、内容をMETA-INF
ディレクトリのapplication.xmlファイルにコピーします。これまでと同様、ファイルがXMLプロローグ(<?xml version="1.0"?>
)で始まっていることを確認します。このファイルを含め、すべてのXMLファイルでプロローグの前に空白文字がないことを確認してください。
web.xml
ファイルをインストールします。
ここでも、展開デプロイで使用したサンプルweb.xml
ファイルを再利用できます。前述のサンプルweb.xml
ファイルから、内容をHelloWorldWebApp/WEB-INF
ディレクトリのweb.xml
ファイルにコピーします。
前述のサンプルHelloWorld.uixの内容を、HelloWorldWebAppディレクトリのHelloWorld.uixファイルにコピーします。
uix2-install.zipファイルのファイルを、HelloWorldWebAppディレクトリに解凍します。
WEB-INFの下にlibディレクトリを作成し、必要なJARファイルをすべてコピーします。
UIXのインストール可能リソース・ファイルおよびすべての依存JARファイルのプライベート・コピーを含めることで、EARファイルが、J2EEアプリケーション・サーバーにデプロイできる自己完結型アプリケーションになります。ただし、UIXリソースおよび必要なJARファイルすべてのプライベート・コピーを使用することが、すべてのデプロイに適しているとはかぎりません。たとえば、多くのWebアプリケーションをホストしているOC4Jインスタンスにデプロイする場合は、JARファイルをすべてのアプリケーションで共有できる共通の場所にインストールする方が効率的です。この場合、前述の「クラスパスの設定」で説明したように、各JARファイルのserver.xmlファイルに<library>
要素を追加する必要があります。
同様に、複数のWebアプリケーションでは、UIXリソース・ファイル(イメージ、スタイルシートなど)の共通のバージョンを共有するとさらに効率的です。この構成の設定方法の詳細は、「UIXのインストール可能リソースの共有」のセクションを参照してください。
EARファイル形式では、アプリケーション・ディレクトリおよびアプリケーション・ファイルすべてのアーカイブに、JARファイル形式を使用します。したがって、基本的にEARファイルは、特定のディレクトリ構造およびメタデータ・ファイルを所有したJARファイルです。必要なディレクトリ構造はすでに作成済で、すべての構成ファイルも所定の場所にコピーしてあります。次の手順では、アーカイブ・ファイルを作成します。
EARファイルの作成に使用できるツールは数多くありますが、最も簡単に使用できるのは、JDKとともに出荷されるjar
コマンドです。サンプル・アプリケーションのEARファイルを作成するには、コンソールまたは端末のウィンドウを起動し、カレント・ディレクトリを、作成したディレクトリ構造の最上位レベルに変更します。(2つの子ディレクトリ、META-INFおよびHelloWorldWebAppが存在します。)その後で、次のコマンドを実行します。
jar -cvf ../helloworld.ear .
1番目の引数、「-cvf
」は、新規EARファイルが冗長出力で作成されることを示します。2番目の引数は、EARファイルの名前です。この場合、EARファイルをそれ自体に追加しようと試行し続けることを回避するため、EARファイルを親ディレクトリに作成するよう指定します。最後の引数、「.」は、カレント・ディレクトリの内容すべてがアーカイブされることを示します。
EARファイルを作成した後は、OC4Jにそれを認識させる必要があります。これを行うには、次の要素を<application-server>
要素の子としてj2ee/home/config/server.xml構成ファイルに追加してください。
<application name="HelloWorldApp"
path="{your path}/helloworld.ear"
auto-start="true"/>
必ず、使用するファイル・システムのhelloworld.earファイルへの適切なパスに置き換えてください。
OC4Jでの展開Webアプリケーションのデプロイで説明したように、各Webアプリケーションは、Webブラウザを介してアクセスできるようURLにバインドする必要があります。このバインドを指定するには、次の要素を<web-site>
要素の子としてj2ee/home/config/default-web-site.xml
構成ファイルに追加します。
<web-app application="HelloWorldApp"
name="HelloWorldWebApp"
root="/greetings"/>
EARファイルのデプロイをテストする準備が整いました。この手順は、EARファイルでのデプロイ、展開ファイル構造でのデプロイに関係なく同じであるため、すでに使用した前述の手順に従ってください。
Tomcatは、Apache Software FoundationのJakartaプロジェクトで開発されたPure Javaのサーブレット・エンジンです。Tomcatの最新バージョン、Tomcat 4.0では、サーブレットAPIのバージョン2.3をサポートします。このセクションでは、Tomcatサーブレット・エンジンでの「Hello, World!」サンプル・アプリケーションのデプロイに必要な手順を説明します。
Tomcatバイナリは、Apache JakartaのWebサイト(http://jakarta.apache.org/tomcat/index.html
)からダウンロードできます。Tomcatは、jakarta-tomcat ZIPファイルを解凍して簡単にインストールできます。解凍により、jakarta-tomcat
ディレクトリの下にディレクトリ構造が作成されます。インストールをテストするには、jakarta-tomcat/bin
ディレクトリのstartup.bat
スクリプト(Windows)またはstartup.sh
スクリプト(UNIX)を実行し、Tomcatを起動します。
Tomcatは、デフォルト・ポートとして8080を使用します。Tomcatの起動後、http://localhost:8080
で初期画面ページを表示できます。(ブラウザのプロキシ設定によっては、マシンの完全なドメイン名を指定する必要があります)。
Tomcat 4.0は、OC4Jと同様に、サーブレット2.3対応のサーブレット・エンジンです。サーブレットAPIの最新バージョンでは、すべてのWebアプリケーションに対して固有のディレクトリ構造および構成ファイル形式を定義しているため、この時点で、ほとんどのインストール・プロセスについて理解している必要があります。次の手順では、UIXベースのWebアプリケーションを展開ファイル構成でデプロイする方法を示します。
Tomcatでは、Webアプリケーション・ディレクトリの名前は、アプリケーションにアクセスするためのWebパス・ルートとしても使用されます。greetingsという名前を使用し、/greetings/HelloWorld.uix
というURLでHelloWorld.uix
文書にアクセスできるようにします。
jakarta-tomcat/webapps
ディレクトリの下にgreetings
およびgreetings/WEB-INF
ディレクトリを作成します。
web.xml
ファイルをインストールします。
サーブレット2.2以上の仕様ではweb.xml
ファイル形式を定義しているため、OC4Jのデプロイで使用したweb.xmlを再利用できます。この文書の内容を、jakarta-tomcat/webapps/greetings/WEB-INFディレクトリのweb.xml
ファイルにコピーします。XMLプロローグの前の空白文字を必ず削除してください。
前述のHelloWorld UIX文書から、内容をgreetingsディレクトリのHelloWorld.uix
ファイルにコピーします。このディレクトリが、Webアプリケーションのドキュメント・ルートになります。
uix2-install.zipファイルのファイルを、greetingsディレクトリに解凍します。
uix2.jar
、xmlparserv2.jar
、share.jar
およびregexp.jar
をgreetings/WEB-INF/lib
ディレクトリにコピーします。1つのTomcatインスタンスで複数のUIXベースのWebアプリケーションを実行する場合は、jakarta-tomcat/lib
ディレクトリにJARファイルを配置します。Tomcatは、このディレクトリにあるJARを自動的にクラスパスに追加します。
jakarta-tomcat/bin/startup.bat
またはstartup.sh
スクリプトを実行してTomcatを起動します。次のいずれかのURLで、「Hello, World!」メッセージを表示できます。
http://localhost:8080/greetings/HelloWorld.uix
http://localhost:8080/greetings/uix/HelloWorld
ページが正しく表示されない場合は、Tomcatがエラー・メッセージを記録していないかコンソール・ウィンドウを確認してください。Tomcatは、jakarta-tomcat/logs
の下のログ・ファイルにもエラー・メッセージを記録します。
Apache JServは旧来のサーブレット・エンジンで、サーブレットAPIの最新バージョンはサポートされていません。JServがサポートするのは、サーブレットAPIのバージョン2.0のみです。サーブレットAPIのバージョン2.1は1998年に初めて公開され、サーブレットAPIの現在のバージョンである2.3は、すでにほとんどのサーブレット・エンジンでサポートされています。ただし、Oracle9iASは現在もJServをサポートしているため、UIXはサーブレットAPIのバージョン2.0との互換性を保持しています。
このセクションでは、JServインスタンスのデフォルト・サーブレット・ゾーンにUIXアプリケーションをインストールする方法を説明します。JServの実用バージョンが、Oracle9iASの最新リリースとともにすでにインストール済であると想定します。JServのインストール方法の説明は、このドキュメントの対象範囲外です。まだJServをインストールしていない場合は、OC4Jなどの最新のサーブレット・エンジンを使用することをお薦めします。
JServは、サーブレット2.2の公開期間中に展開されたWebアプリケーション仕様より前のものであるため、JServへのデプロイは、OC4JおよびTomcatなどの最新サーブレット・エンジンへのデプロイとはまったく異なります。JServでは、Webアプリケーションの作成および構成よりも、サーブレット・クラスの別名を指定することが必要です。次の手順では、JServでサンプル・アプリケーションを設定するプロセスを説明します。
サーブレット別名は、サーブレット・ゾーン固有のプロパティ・ファイルで、サーブレット・ゾーンごとに定義されます。例として、BajaServlet
をデフォルト・サーブレット・ゾーンにインストールし、uixという別名を定義します。これにより、BajaServlet
を/servlets/uixというURLで起動できるようになります。次の行を、Apache/Jserv/etcディレクトリのzone.propertiesに追加します。
servlet.uix.code=oracle.cabo.servlet.BajaServlet
次の行を、Apache/Jserv/etcディレクトリのzone.propertiesファイルに追加します。
servlet.uix.initArgs=oracle.cabo.servlet.pageBroker=oracle.cabo.servlet.xml.UIXPageBroker
この文は、ページ・ブローカとしてUIXPageBroker
を使用することを指定します。
前述のHelloWorld UIXの内容を、Webサーバーのドキュメント・ルート(通常、htdocs)のHelloWorld.uixファイルにコピーします。
uix2-install.zipファイルを、Webサーバーのドキュメント・ルートに解凍します。
UIX JARファイルおよびすべての依存性に対して、wrapper.classpathエントリをApache/Jserv/etc/jserv.properties構成ファイルに追加する必要があります。ファイル・システムの実際のパスに置き換えて、次の行を追加します。
wrapper.classpath={your path}/uix2.jar
wrapper.classpath={your path}/share.jar
wrapper.classpath={your path}/xmlparserv2.jar
wrapper.classpath={your path}/regexp.jar
この手順を完了した後で、(JServインスタンスが自動起動するよう構成されているとの想定で、apachectl start
コマンドを使用して)Apache Webサーバーを起動して次のURLに移動すると、HelloWorld.uix文書が表示されます。
http://localhost:7778/servlets/uix/HelloWorld
インストールのポート番号の調整が必要な場合があります。Apacheインスタンスで実際に使用するポートを決定するには、httpd.confファイルでPortエントリを検索してください。
問題が発生した場合は、Jserv/logs/jserv.log、Apache/logs/access_log、Apache/logs/error_logファイルでエラー・メッセージを確認してください。
UIXでは、使用するXMLパーサーや、ファイル・システムでのUIXファイルの検索場所など、UIXアプリケーションの様々な面の構成に使用する各種の初期化パラメータを公開しています。
OC4JおよびTomcatなど、サーブレットAPI 2.2以上をサポートするサーブレット・エンジンでは、初期化パラメータはuix-config.xml
内で、サーブレット初期化パラメータまたはコンテキスト初期化パラメータとして指定できます。uix-config.xml
ファイルの設定方法の詳細は、「構成」のトピックを参照してください。サーブレット初期化パラメータは、特定のサーブレット・インスタンスについて固有です。これらのパラメータは、<init-param>
要素を使用してアプリケーションのweb.xml
ファイルで指定されます。たとえば、次のサンプルでは、oracle.cabo.image.headless
初期化パラメータを使用して動的イメージ生成を無効にする方法を示しています。
<web-app>
<servlet>
<!-- Define the servlet and PageBroker here... -->
<!-- A servlet initialization parameter -->
<init-param>
<param-name>oracle.cabo.image.headless</param-name>
<param-value>true</param-value>
</init-param>
</servlet>
</web-app>
<init-param>
要素が<servlet>
要素に含まれていることに注意してください。このサーブレット初期化パラメータの値は、この特定のサーブレット・インスタンスについて固有です。
これはuix-config.xml
内でも指定できます。
<?xml version="1.0" encoding="ISO-8859-1"?>
<configurations xmlns="http://xmlns.oracle.com/uix/config">
<default-configuration>
<headless>true</headless>
</default-configuration>
</configurations>
サーブレット初期化パラメータとは異なり、コンテキスト初期化パラメータはWebアプリケーション全体で1回指定され、特定のサーブレット・インスタンスには関連していません。このパラメータは<context-param>
要素を使用して指定されます。
<web-app>
<!-- A context initialization parameter -->
<context-param>
<param-name>oracle.cabo.image.headless</param-name>
<param-value>true</param-value>
</context-param>
</web-app>
<context-param>
要素は<web-app>
要素の子であることに注意してください。コンテキスト初期化パラメータの値は、Webアプリケーションに対してグローバルです。
サーブレット初期化パラメータではなくコンテキスト初期化パラメータを使用する利点の1つに、OC4Jではデプロイメント時にコンテキスト初期化パラメータの値をオーバーライドできるという点があります。コンテキスト初期化パラメータに対するデプロイメント固有の新しい値は、<context-param-mapping>
要素を使用して、Webアプリケーションのorion-web.xml
ファイルで指定できます。たとえば、次のorion-web.xml
ファイルは、前述のweb.xml
ファイル内に指定したoracle.cabo.image.headless
値をオーバーライドします。
<?xml version="1.0"?>
<!DOCTYPE orion-web-app PUBLIC "-//Evermind//DTD Orion Web Application 2.3//EN" "http://xmlns.oracle.com/ias/dtds/orion-web.dtd">
<orion-web-app>
<!-- Set a deployment-specific value for the headless parameter -->
<context-param-mapping name="oracle.cabo.image.headless">false</context-param-mapping>
</orion-web-app>
<context-param-mapping>
メカニズムがない場合、デプロイヤがuix-config.xml
またはweb.xml
ファイル内で直接初期化パラメータの値を変更する必要があります。これらのファイルは、EARファイル内にバンドルされたWARファイル内部に埋め込まれている可能性があるため、この作業は見かけよりも困難です。orion-web.xml
ファイルに新しいパラメータ値を設定する方が、より迅速かつ明瞭な方法です。
開発者が、デフォルトで設定する初期化パラメータを決定する際に注意すべき点があります。OC4Jでは、orion-web.xml
ファイルで、web.xml
ファイル内に指定されたコンテキスト初期化パラメータしかオーバーライドできません。このため、web.xml
ファイルを作成する際、顧客が設定可能なコンテキスト初期化パラメータについては必ずデフォルト(または空の)値を追加してください。
Apache JServなどの旧サーブレット・エンジンでは、初期化パラメータの指定に対して、固有のメカニズムを定義しています。JServでは、初期化パラメータは、servlet.<alias>.initArgs構文を介してjserv.propertiesで指定します。
UIXサーブレット初期化パラメータは、1つを除いてすべてオプションです。UIX Controllerを使用する場合は、oracle.cabo.servlet.pageBroker
パラメータを指定する必要があります。
次の表は、パラメータを定義するクラスの名前を含め、UIXでサポートされる各サーブレット初期化パラメータをリストしたものです。特定のパラメータは、アプリケーションで定義クラスまたはそのサブクラスの1つを使用する場合にのみ使用可能になります。
名前 | 定義クラス | 値 |
---|---|---|
oracle.cabo.servlet.pageBroker | BajaServlet | 使用するPageBroker クラスの完全修飾クラス名。たとえば、oracle.cabo.servlet.xml.UIXPageBroker のように入力します。この初期化パラメータは、UIX Controllerを使用するすべてのアプリケーションに対して指定する必要があります。 |
oracle.cabo.servlet.defaultPage | AbstractPageBroker | 要求されたURLにページ名が指定されていない場合に使用するデフォルトのPage の名前。
|
oracle.cabo.servlet.event.pageFlowEngine | AbstractPageBroker | 使用するPageFlowEngine の完全修飾クラス名。PageFlowEngine が指定されていない場合は、TrivialPageFlowEngine のインスタンスが使用されます。
|
oracle.cabo.servlet.loginPage | TrivialPageFlowEngine | ログインが必要な場合に表示するPage の名前。
|
oracle.cabo.servlet.loggedInKey | TrivialPageFlowEngine | ユーザーがログインしているかを確認するために使用するキーの名前。このキーが設定されている場合、TrivialPageFlowEngine では、このキーと関連付けられた値のHttpSession オブジェクトを調べます。値が検出されない場合、ユーザーは、oracle.cabo.servlet.loginPage 初期化パラメータで指定したページに強制的にログインされます。
|
oracle.cabo.ui.UIExtensions | BaseUIPageBroker | 完全修飾クラス名のカンマ区切りのリスト。リストの各クラスは、UIExtension インタフェースを実装する必要があります。各UIExtension は、BaseUIPageBroker によってインスタンス化および登録されます。
|
oracle.cabo.image.servletURL | BaseUIPageBroker | 任意の動的イメージ生成リクエストに使用するImageServlet インスタンスの場所を指定するURL。
|
oracle.cabo.image.headless | BaseUIPageBroker | ヘッドレス環境でXサーバー要件を軽減するための、動的イメージ生成を使用不可にするブール型パラメータ。true に設定した場合、UIXはイメージの生成を試行しないため、Xサーバー接続は不要です。イメージ・キャッシュにすでに存在するイメージは、そのまま使用できます。デフォルトはfalse です。
|
oracle.cabo.servlet.xml.UIXPath | UIXPageBroker | UIXファイルを含むディレクトリへの完全ファイル・システム・パス。指定されない場合は、UIXPageBroker は、Webアプリケーション・パス(たとえば、getRealPath() )でUIXファイルを検索します。
|
oracle.cabo.servlet.xml.TemplateLibraries | UIXPageBroker | テンプレート・ライブラリ・ファイルのカンマ区切りのリスト。それぞれがロードされ、自動的に登録されるため、開発者はそれらを明示的に指定する必要ありません。 |
oracle.cabo.servlet.xml.XMLProvider | UIXPageBroker | XMLProviderインタフェースの実装の完全修飾クラス名。指定されない場合は、Oracle XML Parserが使用されます。 |
oracle.cabo.servlet.xml.checkModified | UIXPageBroker | サーバーが稼働中に行われたUIXファイルへの変更の確認を使用可または使用不可にするために使用するブール型パラメータ。checkModifiedがtrueに設定されている場合、UIXPageBroker は、リクエストのたびに基本UIX文書への変更を調べます。UIXファイルに行った変更を、ファイルを保存してブラウザをリフレッシュすることで表示できるため、特に開発時に有用です。ただし、リクエストのたびにUIXファイルのタイム・スタンプを調べる必要があるため、パフォーマンスに若干の影響があります。したがって、本番環境でのデプロイでは、checkModified をfalse に設定し、不要なファイル・システム・チェックを回避することが必要です。デフォルトはtrue です。
|
このトピックで説明したサンプル・インストールでは、パフォーマンスよりも構成の容易さを優先しました。最適化の価値があるものとして、UIXのインストール可能リソース・ファイルの使用があげられます。UIXのインストール可能リソース・ファイルとは、UIXで使用するイメージ、スタイルシート、JSPライブラリ・ファイル、およびJavaScriptライブラリ・ファイルです。サンプル・インストールでは、Webアプリケーションごとにこれらのファイルのコピーが存在するという、最も単純な構成を使用しました。これは非常に合理的な構成ですが、UIXのインストール可能リソース・ファイルの単一セットを複数のWebアプリケーションで共有可能にするとさらに適切な構成になります。
UIXリソース・ファイルを共有すると、ディスク・スペースの使用量は減りますが、パフォーマンスの点ではそれほど効果はありません。重要なことは、ブラウザおよび他のキャッシュ・テクノロジにおいて、同じイメージ、スタイルシートなどの別のコピーをダウンロードおよびキャッシュすることを回避できるため、UIXリソース・ファイルの共有により、サーバーに送られる多くのHTTPリクエストを削減できることです。WebアプリケーションごとにUIXリソース・ファイルのコピーを保持する場合、ファイルは、使用するWebアプリケーションに応じてそれぞれ別のURLからアクセスされます。Webアプリケーション間がリソースを共有することで、ブラウザでは、共有リソースを参照するすべてのアプリケーションに対して各リソース・ファイルをダウンロードすることが1回で済みます。
UIXのインストール可能リソース・ファイルのコピーの数を減らすと、新バージョンのUIXにアップグレードする際に移行が容易になるという利点もあります。新バージョンのUIXでは、新規のイメージ、スタイルまたはJavaScriptライブラリが導入される予定です。また、既存のファイルの機能拡張またはバグ修正が組み込まれる可能性もあります。各WebアプリケーションにUIXのインストール可能リソース・ファイルのプライベート・コピーがあると、新バージョンのUIXへのアップグレードは難しくなります。最悪の場合、すべてのWARおよびEARファイルのパッケージとデプロイをやり直す必要があります。アプリケーション間でUIXリソース・ファイルの1つのコピーを共有することで、アップグレードのプロセスを大幅に簡略化できます。
ここでは、UIXのインストール可能リソース・ファイルを、複数のUIXアプリケーション間で共有するいくつかの方法について説明します。
複数のWebアプリケーション間でUIXリソース・ファイルを共有するには、ファイルをWebアプリケーションおよびWebブラウザの両方からアクセスできる場所にインストールする必要があります。通常、これには2つの方法があります。Webブラウザからリソース・ファイルへのアクセスを可能にするため共有リソースを、サーブレット・コンテナにインストールするか、もしくはWebサーバー経由によるWebアプリケーションのデプロイ時に、Webサーバー自体にインストールします。UIXのインストール可能リソース・ファイルをサーブレット・コンテナにデプロイする場合、これらのファイルの配置場所として最もわかりやすいのは、デフォルトWebアプリケーションのルート・ディレクトリです。
OC4Jでは、j2ee/home/default-web-appディレクトリがデフォルトWebアプリケーションのドキュメント・ルートになります。UIXリソース・ファイルをj2ee/home/default-web-appの直下にインストールすることで、/caboで始まるURLを介してこれらのファイルにアクセスできます。たとえば、UIXイメージをj2ee/home/default-web-app/cabo/imagesディレクトリの下に配置すると、/cabo/imagesで始まるURLを介してアクセスできます。Tomcatでは、デフォルトWebアプリケーションはwebapps/Rootディレクトリでホストされます。
uix2-install.zipファイルをデフォルトWebアプリケーションのルート・ディレクトリに解凍した後、これらのリソースを使用するようにUIXを構成します。デフォルトで、UIXは、現行のWebアプリケーションのルート・ディレクトリを基準にしてリソースを検索します。ただし、この場所は、Configuration APIを使用して明示的にオーバーライドできます。特に、ConfigurationImpl.putFullURIAndPath()
メソッドは、UIXリソース・ファイルの新規URIおよびパスの指定に使用できます。
たとえば、UIXリソース・ファイルを/private/oc4j/j2ee/home/default-web-app/caboディレクトリに再配置すると想定し、次のコールをConfigurationImpl.putFullURIAndPath()
に行います。
configImpl.putFullURIAndPath(Configuration.BASE_DIRECTORY,
"/cabo",
"/private/oc4j/j2ee/home/default-web-app/cabo");
このコールは、/private/oc4j/j2ee/home/default-web-app/caboの下にあるすべてのリソース・ファイルを検索するようUIXを再構成します。これらのファイルを参照する際にUIXで生成するURLは、たとえば/cabo/images/error.gifのように/caboで始まります。
当然のことながら、実際に使用するパスはプラットフォームおよびマシンに依存するため、Webアプリケーションではマシン固有のパスをハードコードしません。もう1つの方法として、サーブレット初期化パラメータを介してデプロイ時にパスを設定できるようにする方法があります。次のサンプルPageBroker
の実装は、この機能を実装する方法の1つです。
import oracle.cabo.servlet.xml.UIXPageBroker;
import javax.servlet.Servlet;
import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import oracle.cabo.share.config.ConfigurationImpl;
import oracle.cabo.servlet.xml.UIXPageBroker;
public class CommonResourcePageBroker extends UIXPageBroker
{
/**
* Override of BaseUIPageBroker.createDefaultConfiguration().
*/
protected ConfigurationImpl createDefaultConfiguration()
{
ConfigurationImpl impl = super.createDefaultConfiguration();
// Get the init param value from the ServletConfig
ServletConfig config = getServlet().getServletConfig();
String path = config.getInitParameter(_PATH_KEY);
// If the path has been specified as an init param, reconfigure
// the Configuration object to use the specified path
if (path != null)
{
impl.putFullURIAndPath(impl.BASE_DIRECTORY, "/cabo", path);
}
return impl;
}
// Key for the common path servlet initialization parameter
private static final String _PATH_KEY = "demo.CommonResourcePath";
}
このサンプルPageBroker
の実装は、demo.CommonResourcePathという名前のサーブレット初期化パラメータを検索します。この初期化パラメータが指定されている場合、その値は、Configuration.BASE_DIRECTORY
のパスとして使用されます。
このサンプルPageBroker
を使用するよう「Hello, World!」アプリケーションを更新し、web.xml
ファイルに若干の変更を加えて共有リソース・ファイルへのパスを指定できます。まず、PageBroker
初期化パラメータを更新します。
<init-param>
<param-name>oracle.cabo.servlet.pageBroker</param-name>
<param-value>CommonResourcePageBroker</param-value>
</init-param>
次に、UIXリソースの場所を指定する新規パラメータを追加します。
<init-param>
<param-name>demo.CommonResourcePath</param-name>
<param-value>/private/oc4j/j2ee/home/default-web-app/cabo</param-value>
</init-param>
このように初期化パラメータを公開することで、柔軟な方法でUIXリソース・ファイルを再配置できます。新規マシン固有の場所は、デプロイ時に必要に応じて定義できます。ただし、初期化パラメータは、この機能を実装する唯一の方法ではありません。他のアプリケーション固有の構成メカニズムを使用しても、同じ結果が得られます。
デフォルトWebアプリケーション内にUIXリソース・ファイルの共有デプロイメントを設定する場合、非常に多くの構成作業を行う必要があります。この余分な構成作業を避けるため、UIXでは、Webアプリケーション間でUIXリソース・ファイルを共有するための代替メカニズムをサポートしています。UIXリソース・ファイルのプライベート・コピーが現行のWebアプリケーションの下に見つからない場合、UIXは、Configuration.BASE_DIRECTORY
URIにバインドされているWebアプリケーションの下でUIXリソース・ファイルの共有コピーを検索します。UIXリソース・ファイルを含むWebアプリケーションがURIで見つかった場合、これらの共有ファイルを使用するようにUIXが自動的に再構成されます。この場合、特別な構成コードを記述しなくても、複数のアプリケーション間でUIXのインストール可能リソース・ファイルを共有できます。
現行のアプリケーション内に専用のUIXリソース・ファイルがない場合、UIXは、サーブレットAPIのServletContext.getContext()
メソッドを使用して、UIXのインストール可能リソース・ファイルを含む別のWebアプリケーションを検索します。このメソッドは、検索するWebアプリケーションのベースURIを取得します。指定されたURIでWebアプリケーションが見つかると、そのWebアプリケーションに関連付けられたServletContext
インスタンスが返されます。その後は、ServletContext.getRealPath()
メソッドを使用して、ファイル・システム上のWebアプリケーションの内容(ここでは、UIXのインストール可能リソース・ファイル)を検索できるようになります。
UIXでは、ServletContext.getContext()
メソッドを使用して、Configuration.BASE_DIRECTORY
URIにバインドされているWebアプリケーションを検索します。デフォルトでは、BASE_DIRECTORY
URIは/caboに設定されていますが、この値はConfigurationImpl.putRelativeURI()
またはConfigurationImpl.putFullURIAndPath()
メソッドを使用して変更できます。UIXは、BASE_DIRECTORY
URIにバインドされているWebアプリケーションが見つかると、このWebアプリケーションにUIXのインストール可能リソース・ファイルが含まれるかどうかをチェックします。含まれていた場合は、これらのリソース・ファイルを使用するようにUIXが自動的に再構成されます。たとえば、現行のWebアプリケーションの下のファイルを参照するURL(サンプル・アプリケーションでは/greeting/cabo/images/t.gif)ではなく、共有のインストール可能リソース・ファイルに直接マップするURL(/cabo/images/t.gif)が生成されます。
共有Webアプリケーション内にデプロイされたリソース・ファイルを活用できるWebアプリケーションの数に制限はありません。また、アプリケーション固有の構成コードを記述したり、初期化パラメータや構成パラメータを設定する必要はありません。この共有リソース・ファイルのデプロイメントを有効にするには、2つのステップを行うだけです。最初に、BASE_DIRECTORY
URI(通常は/cabo)にバインドされたWebアプリケーション内にリソース・ファイルをデプロイします。次に、アプリケーションにあるUIXリソース・ファイルのプライベート・コピーを削除するだけで、同じサーブレット・コンテナ内にデプロイされたWebアプリケーションはこれらのリソース・ファイルを利用できます。残りの処理はUIXにより行われます。
以降のステップでは、UIXのインストール可能リソース・ファイルをOC4JのWebアプリケーションにデプロイする方法を説明します。これらのステップは、「OC4JでのUIXアプリケーションのデプロイ」で説明されているステップのサブセットです。
アプリケーションにUIXResourcesAppという名前を付け、j2ee/home/applications/UIXResourcesAppにアプリケーション・ディレクトリを作成します。
UIXリソース・アプリケーションに対して次のapplication.xmlファイルを使用します。
<?xml version="1.0"?>
<!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN" "http://java.sun.com/dtd/application_1_3.dtd">
<application>
<display-name>UIXResourcesApp</display-name>
<module>
<web>
<web-uri>cabo</web-uri>
<context-root>/</context-root>
</web>
</module>
</application>
<web-uri>
をcaboに設定したのは、UIXのインストール可能リソース・ファイルを含むWebアプリケーションに対して使用するURI/ディレクトリ名がcaboであるためです。
application.xmlファイルをインストールするには、j2ee/home/applications/UIXResourcesApp/META-INFディレクトリを作成し、前述の内容をapplication.xmlファイルにコピーします。通常どおり、ブラウザの内容をapplication.xmlファイルにコピーする場合は、必ずファイルの先頭の空白を削除してください。
uix2-install.zipをj2ee/home/applications/UIXResourcesAppディレクトリに解凍します。これにより、j2ee/home/applications/UIXResourcesApp/caboの下にimages、styles、jspsおよびjsLibsディレクトリが作成されます。
web.xml
ファイルをインストールします。
j2ee/home/applications/UIXResourcesApp/cabo/WEB-INFディレクトリを作成し、次の内容をweb.xml
ファイルにコピーします。
<?xml version="1.0"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/j2ee/dtds/web-app_2_3.dtd">
<web-app>
</web-app>
web.xml
ファイルは基本的に空であることに注意してください。サーブレットは定義していませんが、Webアプリケーションをデプロイするにはweb.xml
ファイルが必要です。
次のエントリをj2ee/home/configディレクトリ内のserver.xmlファイルに追加します。
<application name="UIXResourcesApp"
path="{your path}/j2ee/home/applications/UIXResourcesApp"
auto-start="true"/>
次の要素を<web-site>
ルート要素の子としてj2ee/home/config/default-web-site.xmlファイルに追加します。
<web-app application="UIXResourcesApp"
name="cabo"
root="/cabo"/>
注意: UIXでUIXリソース・ファイルの検索を可能にするには、Webアプリケーションのバインドに使用されるベースURIが、そのWebアプリケーションの名前(およびディレクトリ名)と完全に一致する必要があります。たとえば、Configuration.BASE_DIRECTORY
のURIが/uixi(UIXインストール可能ファイル)に設定されている場合、次のバインドでは不十分です。
<web-app application="UIXResourcesApp"
name="cabo"
root="/uixi"/>
/uixiというURIの、UIXのインストール可能ファイルへのアクセスを可能にするためには、このバインドで十分ですが、この場合、UIXはファイル・システム上のファイルを検索できません。正しくは、UIXのインストール可能リソース・ファイルをuixiという名前のWebアプリケーション/ディレクトリ内に配置し、次のバインドを使用します。
<web-app application="UIXResourcesApp"
name="uixi"
root="/uixi"/>
Webアプリケーションの名前が、Webアプリケーションのバインドに使用されているベースURIと一致していない場合、UIXのインストール可能リソース・ファイルをUIXは検索できません。
サンプル・アプリケーションでは、UIXリソース・ファイルをj2ee/home/applications/HelloWorldApp/HelloWorldWebApp/cabo/ディレクトリの下にインストールしています。このディレクトリ内にUIXリソース・ファイルが見つかると、これらのファイルのWebアプリケーション固有のコピーが共有コピーよりも優先されます。このため、/caboというWebアプリケーション内の共有されているUIXのインストール可能リソース・ファイルを使用するには、HelloWorldWebAppからcaboディレクトリを削除します。
UIXのインストール可能リソース・ファイルがBASE_DIRECTORY
URIでWebアプリケーション内にデプロイされた後は、同じサーブレット・エンジン・インスタンスにデプロイされた新しいWebアプリケーションは、これらのファイルのプライベート・コピーをインストールさえしなければ、共有のインストール可能ファイルを使用できます。
ほとんどのサーブレット・エンジンは、サーブレット・エンジンとしてもWebサーバーとしても機能しますが、Webサーバーを経由してサーブレット・エンジン・インスタンスをデプロイすることもしばしばあります。つまり、送られてきたHTTPリクエストはまずWebサーバーによって処理され、サーブレットまたはJSPを対象としているリクエストのみがサーブレット・エンジンに転送されます。この構成では、さらに別の方法でUIXのインストール可能リソース・ファイルを共有できます。UIXリソース・ファイルをWebサーバーにインストールし、同じWebサーバーを介して実行されている複数のアプリケーション間でそのUIXリソース・ファイルを共有できます。
UIXリソース・ファイルをWebサーバーにデプロイする利点の1つは、サーブレット・エンジンへの負荷が軽減されることです。Webサーバーでは、ブラウザへのデータのストリームを行います。サーブレット・エンジンでは、イメージまたはスタイル・シート・データのストリームを行います。これにより、各作業を効率的に実行できます。
Webサーバー経由でデプロイする場合、UIXリソース・ファイルの最もわかりやすい場所は、Webサーバーのドキュメント・ルートです。たとえば、Apache経由でデプロイする場合は、UIXのインストール可能リソースをApache/htdocs/caboディレクトリにインストールできます。UIXリソースをWebサーバーのドキュメント・ルートに配置する1つの利点は、リソースへのアクセスに使用するURLが短くなることです。1つのUIXページに、イメージなどのUIXリソース・ファイルへのURLを多数含めることができるため、これらのURLを短くすることでHTMLコンテンツを小さくできます。
UIXのインストール可能リソース・ファイルをWebサーバーにインストールする場合、これらのディレクトリへのアクセス権限を、サーブレット・エンジンが必ず持つようにすることが非常に重要です。一般に、サーブレット・エンジンとWebサーバーが同じユーザーIDを使用して実行される場合、これは問題になりません。しかし、異なるユーザーIDを使用してこの2つのプロセスが実行された場合は、Webサーバーの下にインストールされたファイルに、サーブレット・エンジンがアクセスできないことがあります。この場合、Webサーバーとサーブレット・エンジンの両方が確実にUIXのインストール可能リソース・ファイルにアクセスできるように、ファイル・システム権限を変更する必要があります。また、UIXでは実行時にスタイル・シートを動的に作成し、これらのファイルをcabo/styles/cacheの下に格納するため、サーブレット・エンジンにはcabo/styleディレクトリへの書込みアクセスが必要です。
UIXのインストール可能リソース・ファイルがWebサーバーにデプロイされたとき、UIXはServletContext.getContext()
を使用してこれらのファイルを自動的に検索できないため、追加の構成ステップが必要です。oracle.cabo.ui.sharedContextPathシステム・プロパティを介して、UIXのインストール可能リソース・ファイルの場所を明示的に指定する必要があります。このプロパティは、Configuration.BASE_DIRECTORY
URIの下の、UIXのインストール可能リソース・ファイルを含む親ディレクトリを指定します。
システム・プロパティの指定には、Java仮想マシンの起動時にコマンドラインで-Dパラメータを使用します。たとえば、UIXのインストール可能リソース・ファイルが/private/oracle/Apache/Apache/htdocs/caboにインストールされている場合は、OC4Jの起動時に次のコマンドを使用します。
java -Doracle.cabo.ui.sharedContextPath=/private/oracle/Apache/Apache/htodcs -jar oc4j.jar
UIXでは、Configuration.BASE_DIRECTORY
に関連付けられたURIを、sharedContextPathプロパティを介して指定されたパスに追加して、UIXのインストール可能リソース・ファイルの完全パスを決定します。
専用Webアプリケーションの解決方法と同様に、UIXでは、UIXリソース・ファイルのローカル・コピーが現行のWebアプリケーションに存在しない場合、これらのファイルの共有コピーのみを使用します。このため、既存のWebアプリケーションがUIXのインストール可能リソース・ファイルの共有コピーを利用できるように、これらのファイルのプライベート・コピーを削除しておく必要があります。ただし、重要な例外が1つあります。Webサーバー経由でUIXリソース・ファイルをデプロイする場合、UIX JSPファイルのコピー(通常はcabo/jspsディレクトリ内にある)が、すべてのWebアプリケーション内で常に保持されている必要があります。これは、WebサーバーがJSPを実行できる場合でも同じです。これは、WebアプリケーションとUIX JSPがJavaオブジェクト(具体的にはConfiguration
インスタンス)を共有するためです。UIXのインストール可能JSPファイルがWebサーバー上にデプロイされ、個別のJVMにデプロイされた場合、JSPとWebアプリケーションでオブジェクト・インスタンスを共有することはできません。
幸い、UIXのインストール可能JSPファイルは変更されないことが保証されているため、この条件は当初の予想ほど負担ではありません。アップグレードのプロセスを簡略化するため、UIX JSPファイルは、uix2.jarファイルに含まれたJavaコードをコールする単なるラッパーになっています。このため、JSPファイル自体を変更しなくてもUIX JSPの機能拡張またはバグ修正を行うことができます。したがって、UIX JSPファイルを各WebアプリケーションまたはWARファイルに一度バンドルすれば、将来これらのファイルは変更されないため、新しいバージョンを選択する必要はありません。
(JSPを除く)UIXリソース・ファイルがWebアプリケーションから削除されると、UIXは、oracle.cabo.ui.sharedContextPathシステム・プロパティを介して指定されたパスを自動的にチェックします。UIXのインストール可能リソース・ファイルがこのパスで検出されると、これらのファイルを参照するようにUIXが自動的に再構成されます。