この章では、OC4Jへのデプロイ用にオープン・ソース・フレームワークでアプリケーションを開発する方法について説明します。次の項が含まれます。
オープン・ソース・フレームワークで構築されたWebアプリケーションをOC4Jで使用できるようにするには、オープン・ソースの実装およびすべての依存ライブラリを含むJARファイルが、OC4J内で利用できる必要があります。デフォルトでは、オープン・ソース・フレームワーク・ライブラリは、OC4Jにおいてグローバル・レベルでは使用できません。
標準的な方法は、必要なJARファイルをWEB-INF/lib
パス上のWebアプリケーションとともにパッケージ化することです。その後は、WebアプリケーションとともにライブラリをOC4Jにデプロイできます。これは最も単純なプロセスですが、結果としてライブラリのインスタンスがWebアプリケーションごとにロードされます。
複数のWebアプリケーション、または単一のJ2EEアプリケーション内の複数のWebモジュールでオープン・ソース・ライブラリが必要な場合は、OC4J固有の共有ライブラリ・メカニズムの方がより現実的な方法です。このメカニズムの場合は、同じライブラリの複数のコピーをロードするのではなく、OC4Jが共有ライブラリに対する単一のクラス・ローダーを作成するため、システム・リソースが効率よく使用されます。
共有ライブラリ・メカニズムを使用するには、「共有ライブラリのインストールと公開のオプション」で説明されているいずれかのオプションを使用して、アプリケーションをホストするOC4Jインスタンスに共有ライブラリをインストールします。その後は、「共有ライブラリをインポートするためのアプリケーションの構成」で説明されているように、共有ライブラリをインポートするように個別のアプリケーションを構成できます。
オープン・ソース・フレームワークの実装を共有ライブラリとして使用できるようにする方法は、次の場合に実用的です。
J2EEアプリケーション(EAR)内のすべてのWebモジュールが、同じバージョンのライブラリを使用する場合
この場合は、EARレベルのorion-application.xml
デプロイメント・ディスクリプタで(「アプリケーションのOC4Jデプロイメント・ディスクリプタでの依存性の宣言」を参照)、またはMANIFEST.MF
ファイルで(「アプリケーションのマニフェスト・ファイルでの依存性の宣言」を参照)共有ライブラリをインポートするようにアプリケーションを構成します。
OC4JにデプロイされているすべてのWebモジュールが、同じバージョンのライブラリを使用する場合
これには、「すべてのデプロイ済アプリケーションで特定の共有ライブラリをインポートするための構成」で説明されているように、共有ライブラリをインポートするようにdefault
アプリケーションを構成する必要があります。この構成を使用した場合、別のバージョンのライブラリがアプリケーションとともにパッケージされていたとしても、アプリケーションはdefault
アプリケーションがインポートするバージョンの共有ライブラリを使用します。
「共有ライブラリをインストールおよび公開するためのオプション」で説明されているいずれかのメカニズムを使用して、共有ライブラリを作成できます。次の例で示すように、Oracle Enterprise Manager 10g Application Server Controlを使用して、OC4JサーバーにXercesパーサーを共有ライブラリとして簡単に追加できます。
「管理」→「共有ライブラリ」の順にクリックします。
「作成」をクリックします。
共有ライブラリの名前を入力します。この例では、xerces.xml
と入力します。
共有ライブラリのバージョンとして、この場合は2.5.0と入力します。
「追加」をクリックして、ライブラリのJARファイルをOC4Jインスタンスにアップロードします。次のApacheライブラリをアップロードします。
xercesImpl.jar
xml-apis.jar
次の共有ライブラリ宣言がORACLE_HOME
/j2ee/
instance
/server.xml
ファイルに追加されます。
<shared-library name="xerces.mxl" version="2.5.0"> <code-source path="xercesImpl.jar"/> <code-source path="xml-apis.jar"/> </shared-library>
オープン・ソース・フレームワークを使用するときは、アプリケーションとともにパッケージされている対応するオープン・ソース・ライブラリとの競合を避けるために、デフォルトでインポートされるOracle共有ライブラリの削除またはオーバーライドが必要になる場合があります。
たとえば、OC4JにパッケージされているOracle XMLパーサーは、OC4Jにデプロイされているすべてのアプリケーションがデフォルトで使用します。Axisベースのアプリケーションなどでは、Xercesパーサー・ライブラリが必要であるため、これは望ましくありません。
この場合、いくつかのオプションがあります。
アプリケーションとともにパッケージされるorion-application.xml
ファイルで、共有ライブラリを削除するように指定します。
<remove-inherited>
タグの使用方法の概要は、「デフォルトでインポートされるOracle共有ライブラリの削除または置換」を参照してください。
デプロイ時にOracle共有ライブラリをインポートしないように、アプリケーションを構成します。
デプロイ時に共有ライブラリを削除する方法の手順を示した例については、「デフォルトでインポートされるOracle共有ライブラリの削除または置換」を参照してください。
必要なオープン・ソースJARファイルがWebモジュール内にパッケージされている場合は、OC4Jがこのローカル・ライブラリを検索してロードするように指定できます。これにより、デフォルトのOracleライブラリのかわりにこのライブラリが使用されます。
手順の例については、「Oracle共有ライブラリの代替としてのパッケージ化されたJARの使用」を参照してください。
次の各項では、Jakarta StrutsをOC4J環境で使用する方法の概要について説明します。
Jakarta Strutsは、Javaサーブレット、JavaServer PagesおよびXMLなどのオープン・スタンダードを使用してWebアプリケーションを構築するためのオープン・ソース・フレームワークです。最新公式リリースのStrutsバージョン1.1で構築したアプリケーションは、最新リリースのOC4Jに簡単にデプロイできます。
Strutsは、Model-View-Controller(MVC)パターンに基づいたモジュール化アプリケーション開発モデルをサポートしています。Strutsを使用することにより、業界標準や実証済設計モデルに基づき、アプリケーションの拡張可能な開発環境を作成できます。Struts MVC対応のWebアプリケーションをOC4Jにデプロイするために、OC4J固有の構成は必要ありません。
Strutsは、Apache Jakartaプロジェクトの一部で、Apache Software Foundationによって運営されています。公式のStrutsのWebサイトにあるユーザー・ガイド、インストール・ガイドおよびその他のドキュメントを参照してください。
http://jakarta.apache.org/struts
注意: Strutsのドキュメントには、Strutsを共有ライブラリとしてインストールすることについての強い推奨事項があります。特に、すべてのアプリケーション・クラスを共有ライブラリに格納しないと、ClassNotFoundException の問題が発生する可能性があることが示されています。
このため、 |
Oracle JDeveloper 10gでは、Struts 1.1フレームワークでのWebアプリケーションの構築を、広くサポートしています。
JDeveloperのStrutsフレームワーク用ソースは、jdev_install
/jakarta-struts/
ディレクトリに格納されています。このディレクトリには、サンプルのWebアプリケーションなど、Apache Strutsのホームページからダウンロードできるものと同じStrutsパッケージが収められています。
JDeveloperには、次のようなStruts開発用機能があります。
Strutsページ・フロー・ダイアグラムでは、パレットから選択したアイコンを使用して、アプリケーションのWebページのフローを描画できます。ダイアグラムでは、アクションやアクション転送などの標準Struts要素が視覚的に表現され、Struts構成ファイルでこれらの要素が自動的に更新されます。
構造ウィンドウとプロパティ・インスペクタを使用して、Struts要素の属性を編集できます。
Struts構成エディタを使用して、Strutsの構成ファイルを直接編集できます。
Strutsフレームワークと連動する大きなカスタムJSPタグ・ライブラリのセットが提供されており、JDeveloperコンポーネント・パレットからStrutsのタグ・ライブラリにアクセスできます。
Strutsのサポートの詳細は、Oracle JDeveloperで提供されているオンライン・ヘルプを参照してください。
Oracle JDeveloperを使用していない場合は、次のJakartaのサイトからStruts 1.1ディストリビューションを直接ダウンロードできます。
http://jakarta.apache.org/site/binindex.cgi
WARファイルとしてパッケージされているサンプル・アプリケーションは、一般的なStrutsを理解するための優れたリソースです。Strutsを使用するために構成されたWARファイルの例が、Strutsアーカイブ・ファイルの/webapps
フォルダにstruts-blank.war
として提供されています。この例は、ユーザーがWebアプリケーションを作成する際に、テンプレートとして使用できます。
このセクションでは、OC4JでのSpring Framework 1.2の使用に関する概要を提供します。次の項目が含まれています。
Springは、Dependency Injection(DI: 依存性注入)設計パターンに基づくオープン・ソースのJava/J2EEアプリケーション・フレームワークで、使用が拡大しています。OC4Jは、Spring Framework 1.2で構築されたアプリケーションを完全にサポートします。この最新リリースのSpringではOracle TopLink統合も広範にサポートされており、永続的データ・アクセスに対するプラットフォームが提供されます。
Strutsと同様に、SpringもModel-View-Controller(MVC)フレームワークを提供し、Spring MVCで構築されたWebアプリケーションは、OC4Jにシームレスにデプロイできます。OC4J固有のデプロイ構成は必要ありません。
Springは永続的データ・アクセスの部分が特に強力で、リレーショナル・データベースと相互作用するWebアプリケーションを構築するための優れたフレームワークとなっています。Springフレームワーク自体に、J2EE Data Access Objects(DAO)設計パターンで構築された永続性レイヤーが含まれています。DAOレイヤーは、オープン・ソースのHibernateや実績のあるOracle TopLinkなどのオブジェクト・リレーショナル・マッピング(ORM)ツールとよく統合されます。
Spring 1.2には、Oracle TopLinkリリース9.0.4および10.1.3に対する広範なサポートが含まれます。この統合により、Plain Old Java Object(POJO)をリレーショナル・データベースに永続化するための強力で高性能のフレームワークが提供されます。
spring-reference.pdf
としてSpringディストリビューションとともに提供されている『Spring Reference Documentation』の第11.4項では、TopLinkとの統合が詳細に解説されています。spring.jar
で提供されている様々なTopLinkクラスについてのドキュメントも提供されています。
Spring 1.2のディストリビューションは、次の場所からZIPファイルで入手できます。
http://www.springframework.org/download
この場所からは、最新のスナップショット・ビルドもダウンロードできます。
『Spring Reference Documentation』は、spring-reference.pdf
としてディストリビューションとともに提供されます。Springには、ベスト・プラクティスを示す複数のサンプル・アプリケーションも同梱されています。これらのサンプルは、独自のアプリケーションに対するテンプレートとして使用できます。
Spring 1.2は7つのモジュールで編成されており、それぞれがJARファイルとしてパッケージされています。コア・モジュールはspring.jar
としてパッケージされており、他のすべてのモジュールが含まれています。ただし、モジュール構造によって、必要なJARファイルのみを提供できるようになっています。
次では、Apache MyFacesを使用して構築されたWebアプリケーションのOC4Jでの動作の概要について説明します。
MyFacesは、Webアプリケーションを構築するためのJavaの標準フレームワークであるJavaServer Faces(JSF)に対する、オープン・ソースの代替実装です。MyFacesは、Apache Foundationの支援を受けて開発されました。
MyFacesは単にJSFのもう1つのフレーバーであるため、MyFacesで構築したWebアプリケーションは、OC4Jに簡単にデプロイできます。OC4J固有の構成変更は必要ありません。
MyFacesのディストリビューションは、次の場所からダウンロードできます。
http://myfaces.apache.org/binary.cgi
フレームワークはmyfaces.jar
としてパッケージされており、OC4JにデプロイされるWebアプリケーションは、このパッケージを使用できる必要があります。
また、このサイトからは、MyFacesフレームワークで構築され、WARファイルとしてパッケージされたWebアプリケーションのセットもダウンロードできます。
core
およびhtml
のタグ・ライブラリに対するtaglib
ディレクティブは、すべてのJSF実装に対して同じです。つまり、たとえばSun RIまたはMyFacesのどちらのライブラリでも、OC4JにデプロイされているJSPを更新せずに使用できます。
MyFacesを使用するWebアプリケーションをデプロイする場合は、アプリケーションから次のライブラリを使用できるようにする必要があります。
myfaces-api.jar
myfaces-impl.jar
あるいは、myfaces-all.jar
を利用することもできます。これには、前述の2つのJARのすべてのファイルが含まれています。ただし、2つのJARファイルを個別に使用すると、特定のライブラリのスワップ・アウトが容易になります。
MyFacesではTomahawkという名前のオープン・ソース拡張ライブラリも提供されており、これにはJDeveloperにパッケージされているSun JSF RIなどのJSF 1.1の互換実装との完全な互換性があります。このコンポーネント拡張を使用する場合は、デプロイされているアプリケーションが次のライブラリを使用できるようにする必要があります。
tomahawk.jar
さらに、ライブラリを使用するすべてのJSPに次のtaglib
ディレクティブを含める必要があります(JDeveloperなどのツールはこれを自動的に行います)。
<%@ taglib uri="http://myfaces.apache.org/tomahawk" prefix="t"%>
Oracle JDeveloperは、Sun JavaServer Facesリファレンス実装(RI)に対する組込みサポートを備えています。ただし、Import Custom JSPタグ・ライブラリ・インタフェースを通して、MyFacesなどの他のJSF実装を使用するように、JDeveloperを簡単に構成できます。
Sun RIとMyFacesの両方の実装をJDeveloperにインストールできます。実際、いずれかの標準実装を使用してJSPを構築した後、使用するライブラリを置き換えるだけで、デプロイ時に別の実装を使用するように変更することさえできます。
JSF、MyFacesおよびOracle ADFの使用に関する追加情報およびハウツー情報については、Oracle Technology Networkで次のJDeveloperページを参照してください。
http://www.oracle.com/technology/products/jdev/index.html
次では、OC4JにデプロイされたアプリケーションでのHibernateの使用の概要について説明します。
Hibernateは、Java環境用のオープン・ソースのオブジェクト・リレーショナル・マッピング(ORM)ツールです。Hibernateは、Java Swingアプリケーション、Javaサーブレット・ベースのアプリケーション、またはEJBセッションBeanを使用するJ2EEアプリケーションでよく使用されます。
Hibernateのライブラリとドキュメントには、次のサイトからアクセスできます。
http://hibernate.org/
デフォルトでOC4JにパッケージされているOracle TopLinkとHibernateのどちらでも、antlr.jar
が使用されます。OC4Jにパッケージされているライブラリと、Hibernateアプリケーションにパッケージされているライブラリの間で、クラスの衝突を避けるためには、アプリケーションによってインポートされるライブラリのセットから、oracle.toplink
共有ライブラリを明示的に削除する必要があります。
詳細は、「デフォルトでインポートされるOracle共有ライブラリの削除または置換」を参照してください。
次では、OC4JでAxisベースのWebサービスを使用する場合の概要について説明します。
Apache Axisは、Webサービスを実装するためのフレームワークとしてよく知られており、広く使用されています。Axis 1.2および1.3に基づくWebサービスを含むアプリケーションは、OC4Jに簡単にデプロイできます。
Axisのライブラリとドキュメントには、次のApacheサイトからアクセスできます。
http://ws.apache.org/axis/
通常、AxisアプリケーションはデフォルトでXerces XMLパーサーを利用します。ただし、アプリケーションにXercesパーサーがパッケージされていない場合は、OC4JにパッケージされているOracle XMLパーサーを安全に使用できます。
XercesライブラリがWebモジュール(WAR)ファイルにパッケージされている場合であっても、Oracle XMLパーサーは、デプロイされるすべてのアプリケーションでデフォルトで使用されるように構成されています。したがって、AxisベースのアプリケーションでXercesパーサーを使用する場合は、OC4Jで提供されているいずれかの共有ライブラリ・メカニズムを使用して、特定のAxisベース・アプリケーションでXercesパーサーが使用されるようにする必要があります。詳細は、「競合を回避するためのインポート済Oracle共有ライブラリの削除」を参照してください。
影響を受けるWebサービスにOracleのJAX-RPCライブラリまたはSAAJライブラリ(jaxrpc-api.jar
およびsaaj-api.jar
)が含まれている場合には、Oracle XMLパーサーを削除しようとするとエラーになることに注意してください。
AxisとOracleは、JAX-RPCライブラリやWSDLライブラリなどのいくつかの重要なWebサービス・ライブラリについて、それぞれ異なる実装を提供します。表6-1は、このような一般的なライブラリの一覧です。
表6-1 Webサービスのライブラリ
Oracle | Axis |
---|---|
|
|
|
|
|
|
現時点では、これらのライブラリには同じクラス実装が含まれているため、AxisアプリケーションをOC4Jにデプロイしても、クラスのロードの問題は発生しません。
ただし、Axisを使用するWebサービスと、Oracleを使用する別のWebサービスを、1つのアプリケーション(EAR)に含めることはできません。特に、JAX-RPCの実装を使用して作成されたWebサービス・クライアントを通して別のWebサービスを呼び出すAxis Webサービスは、サポートされていません。
次の各項では、Jakarta log4jをOC4J環境で使用するための考慮事項について説明します。
log4jフレームワークは、Apache Jakartaプロジェクトのオープン・ソース・プロジェクトで、Apache Software Foundationによって運営されています。このフレームワークは、Javaアプリケーションに対する実行時のロギング操作をサポートするための効率的で柔軟なAPIを提供します。log4jを使用することにより、様々なレベルの警告でメッセージを取り込み、ログ文をコードに挿入することが可能になります。また、システム管理者は、提供されたアプリケーション・コードを変更することなく、アプリケーションの実行時に表示するロギングのレベルを個別に定義できます。
log4jの機能を使用すると、アプリケーションのバイナリ・ファイルを変更せずに、実行時にロギングを行うことが可能です。パフォーマンスを著しく低下させずに、文を出荷時のコードに残しておくことができます。ロギングは構成ファイルによって制御されるため、アプリケーションのバイナリを変更する必要はありません。
次の各項で、log4jライブラリをインストールし、OC4Jで使用するために構成する方法を説明します。幅広いOC4J APIの使用方法はOC4J固有ではないため、このマニュアルでは説明しません。log4jの公式Webサイトにあるドキュメントを参照してください。
http://jakarta.apache.org/log4j/docs/index.html
log4jディストリビューションは、次のサイトから入手可能です。
http://jakarta.apache.org/log4j/docs/download.html
アーカイブ・ファイルをこのサイトからダウンロードします。環境に合った形式(ZIPファイルまたは圧縮済のTARファイル)を選択し、ローカル・ファイル・システムに保存します。
log4jフレームワークを使用すると、外部構成ファイルで指定された設定によってロギング動作を制御し、アプリケーション・コードを変更せずにロギング動作に変更を加えることができます。
外部構成ファイルを使用する方法は、主に3種類あります。各アプローチにより、構成ファイルの名付け方、および実行時にJ2EEアプリケーション・サーバーによってどのように検索されるかが異なります。
次の各項で、これら3種類の方法を説明します。
デフォルトで、log4jはロギング動作の決定に、log4j.properties
またはlog4j.xml
という名前の構成ファイルを使用します。log4jは、実行時に使用可能なクラス・ローダーから、これらのファイルを自動的にロードします。両方のファイルが検出された場合、log4j.xml
が優先されます。
自動構成ファイルを使用するには、OC4Jが使用するCLASSPATHに含まれるディレクトリ内に入れます。次に、これに含まれるものを、ロードの優先順位によって示します。
グローバル・アプリケーション・レベル: /j2ee/
instance
/applib
Webアプリケーション・レベル: /WEB-INF/classes
注意: log4jランタイムは、org.apache.log4j.Logger クラスが初めてコールされた際に、自動構成ファイルを使用して1回のみ構成されます。
log4jライブラリを log4jライブラリを各Webアプリケーション用に、各 詳細は、次のlog4jのWebサイトで、log4jユーザー・メーリング・リストを参照してください。
|
log4jの自動構成に、デフォルト・ファイル名を使用するかわりに代替ファイル名を使用できます。これには、次のように、OC4Jの起動時に追加実行時プロパティを指定します。url
は使用する構成ファイルの位置を指定します。
java -Dlog4j.configuration=url
log4j.configuration
プロパティの指定値が絶対URLの場合、log4jはURLを直接ロードし、構成ファイルとして使用します。
指定値が絶対URLでない場合、log4jは使用可能なクラス・ローダーからロードする構成ファイルの名前として指定値を使用します。
たとえば、OC4Jを次のように起動したとします(折り返された1行のコマンドラインであるとします)。
java -Dlog4j.debug=true -Dlog4j.configuration=file:///d:\temp\foobar.xml -jar oc4j.jar
この場合、log4jはファイルd:\temp\foobar.xml
を構成ファイルとしてロードします。
別の例として、OC4Jを次のように起動したとします。
java -Dlog4j.debug=true -Dlog4j.configuration=foobar.xml -jar oc4j.jar
この場合、log4jは使用可能なクラス・ローダーからfoobar.xml
をロードします。これは、デフォルトの自動構成ファイルlog4j.xml
を使用する場合と同じ仕組みですが、かわりに指定されたファイル名を使用します。
注意: この方法は、より柔軟性がありますが、すべてのデプロイされたアプリケーションの外部構成ファイルが同じ名前である必要があります。 |
自動構成ファイルのローディング・メカニズムに依存するかわりに、一部のアプリケーションでは、外部構成ファイルのロードにプログラム的なアプローチを使用します。この場合、構成ファイルのパスは、アプリケーション・コード内で直接提供されます。これにより、アプリケーションごとに異なるファイル名を使用できます。log4jユーティリティはロギング動作を決定するために、指定された構成ファイル(XML文書またはプロパティ・ファイル)をロードおよび解析します。
次に例を示します。
public void init(ServletContext context) throws ServletException { // Load the barfoo.xml file as the log4j external configuration file. DOMConfigurator("barfoo.xml"); logger = Logger.getLogger(Log4JExample.class); }
この場合、log4jはOC4Jの起動ディレクトリからbarfoo.xml
をロードします。
プログラム的なアプローチを使用すると、開発者やシステム管理者は最大の柔軟性が得られます。構成ファイルには任意の名前を使用でき、任意の位置からロードできます。この場合でも、システム管理者は、アプリケーション・コードを変更せずに、外部構成ファイルによってロギング動作を変更できます。
さらに柔軟性を確保し、アプリケーションに特定の名前と位置をコードしない場合は、ファイル名と位置を標準web.xml
デプロイメント・ディスクリプタ内のパラメータとして提供すると便利です。サーブレットまたはJSPページは、構成ファイルの位置と名前を指定するパラメータ値を読み取り、構成ファイルのロード元の位置を動的に構成します。このプロセスにより、システム管理者は、使用する構成ファイルの名前と位置の両方を選択できます。
次に、構成ファイルの名前と位置を指定しているweb.xml
エントリの例を示します。
<context-param> <param-name>log4j-config-file</param-name> <param-value>/web-inf/classes/app2-log4j-config.xml</param-value> </context-param>
アプリケーションは、デプロイメント・ディスクリプタから位置の値を読み取り、ローカル・ファイル・システム上でファイルへのフルパスを構成し、ファイルをロードします。次に、サンプル・コードを示します。
public void init(ServletContext context) throws ServletException { /* * Read the path to the config file from the web.xml file, * should return something like /web-inf/xxx.xml or web-inf/classes/xxx.xml. */ String configPath = context.getInitParameter("log4j-config-file"); /* * This loads the file based on the base directory of the Web application * as it is deployed on the application server. */ String realPath = context.getRealPath(configPath); if(realPath!=null) DOMConfigurator.configure(realPath); _logger = Logger.getLogger(Log4JExample.class); }
注意: 動作を定義するファイルで、HTTPリクエストからクライアントがアクセスすべきでないものは、Webアプリケーションの/WEB-INF ディレクトリに置くことをお薦めします。(/WEB-INF のサブディレクトリは使用しないでください。)たとえば、log4j.xml がこれに該当します。サーブレット仕様では、/WEB-INF ディレクトリの内部はクライアントからアクセス不可である必要があります。 |
log4jおよび外部構成ファイルを使用するアプリケーションをOC4Jにデプロイする際、log4jがリクエストされた構成ファイルを検索およびロードする方法を表示すると便利な場合があります。これを行うため、log4jではデバッグ・モードが用意されています。デバッグ・モードを使用すると、構成ファイルのロード方法が表示されます。
log4jのデバッグ・モードをオンにするには、次のようにして、OC4Jの起動時に追加実行時プロパティを指定します。
java -Dlog4j.debug=true -jar oc4j.jar
OC4Jにより、次のような出力が表示されます。
Oracle Application Server (9.0.4.0.0) Containers for J2EE initialized log4j: Trying to find [log4j.xml] using context classloader [ClassLoader: [[D:\myprojects\java\log4j\app1\webapp1\WEB-INF\classes], [D:\myprojects\java\log4j\app1\webapp1\WEB-INF\lib/log4j-1.2.7.jar]]]. log4j: Using URL [file:/D:/myprojects/java/log4j/app1/webapp1/WEB-INF/classes/ log4j.xml] for automatic log4j configuration. log4j: Preferred configurator class: org.apache.log4j.xml.DOMConfigurator log4j: System property is :null log4j: Standard DocumentBuilderFactory search succeeded. log4j: DocumentBuilderFactory is oracle.xml.jaxp.JXDocumentBuilderFactory log4j: URL to log4j.dtd is [classloader:/org/apache/log4j/xml/log4j.dtd]. log4j: debug attribute= "null". log4j: Ignoring debug attribute. log4j: Threshold ="null". log4j: Level value for root is [debug]. log4j: root level set to DEBUG log4j: Class name: [org.apache.log4j.FileAppender] log4j: Setting property [file] to [d:/temp/webapp1.out]. log4j: Setting property [append] to [false]. log4j: Parsing layout of class: "org.apache.log4j.PatternLayout" log4j: Setting property [conversionPattern] to [%n%-5p %d{DD/MM/yyyy} d{HH:mm:ss} [%-10c] [%r]%m%n]. log4j: setFile called: d:/temp/webapp1.out, false log4j: setFile ended log4j: Adding appender named [FileAppender] to category [root].
注意: 外部構成ファイルでlog4j:configuration タグのdebug 属性を使用して、デバッグ出力を使用することも可能です。ただしこの場合は、実行されたロード処理は表示されないため、構成ファイルのロード時の問題解決には不向きです。 |
Oracle Application Server 10g(10.1.3.5.0)では、Oracle Web ServicesはJAX-RPCに基づいています。次に示すように、Oracle Web ServicesのかわりにJAX-WS Reference Implementation(RI)を使用するようにOC4Jおよびアプリケーションを構成することで、JAX-WS WebアプリケーションをOC4J 10g(10.1.3.5.0)にデプロイできます。
JAX-WS RIパッケージをダウンロードします。
共有ライブラリとしてJAX-WS RIファイルをOC4Jに公開します。
デプロイ前またはデプロイ時に、Oracle Web Servicesライブラリをアプリケーションからインポート解除します。
Oracle Web Servicesライブラリをインポート解除した後、JAX-WS RI共有ライブラリをアプリケーションにインポートします。
JAX-WS RIファイルを共有ライブラリとして公開すると、「共有ライブラリのインストールと公開のオプション」で説明しているように、OC4Jのインスタンスまたはグループ、もしくはスタンドアロンOC4Jにインストールされます。これらのファイルをWebアプリケーションとともにWEB-INF/lib
パス上でパッケージ化し、WebアプリケーションおよびOC4Jにライブラリをデプロイすることもできます。詳細は「OC4Jでのオープン・ソース・ライブラリのインストール」を参照してください。
共有ライブラリをOC4Jに公開またはデプロイする際の競合やバージョニングの問題を回避するため、JAX-WS RIパッケージにコード・ソースとして付属する、次のようなすべてのJARファイルを追加することをお薦めします。
jaxb-api.jar
saaj-api.jar
resolver.jar
jaxws-tools.jar
streambuffer.jar
jsr173_api.jar
jaxws-api.jar
jsr181-api.jar
stax-ex.jar
jaxb-xjc.jar
saaj-impl.jar
jsr250-api.jar
jaxws-rt.jar
jaxb-impl.jar
sjsxp.jar
FastInfoset.jar
次のURLにあるJAX-WS Reference Implementation Webサイトから、使用するバージョンのJAX-WS RIパッケージをダウンロードします。
https://jax-ws.dev.java.net/
「OC4Jでのオープン・ソース・ライブラリのインストール」または「OC4Jでの共有ライブラリのインストールと公開」の手順に従って、共有ライブラリとしてJAX-WS RIファイルをOC4Jに公開できます。OC4Jのserver.xml
構成ファイルで共有ライブラリの一部としてJAX-WS RIファイルを追加することもできます。
server.xmlでOC4JにJAX-WS RIファイルを追加する手順:
ライブラリ名およびバージョンを次のように指定して、OC4Jのserver.xml
ファイルにJAX-WS RIの<shared-library>
要素を追加します。
server.xml . . . <shared-library name="jaxws20" version="2.0"> </shared-library> . . .
次のようにファイルの相対パスを指定して、<shared-library>要素内で各JAX-WS RIファイルの< code-source>要素を追加します。
server.xml . . . <shared-library name="jaxws20" version="2.0"> <code-source path="jaxb-api.jar"/> <code-source path="saaj-api.jar"/> <code-source path="resolver.jar"/> <code-source path="jaxws-tools.jar"/> <code-source path="streambuffer.jar"/> <code-source path="jsr173_api.jar"/> <code-source path="jaxws-api.jar"/> <code-source path="jsr181-api.jar"/> <code-source path="stax-ex.jar"/> <code-source path="jaxb-xjc.jar"/> <code-source path="saaj-impl.jar"/> <code-source path="jsr250-api.jar"/> <code-source path="jaxws-rt.jar"/> <code-source path="jaxb-impl.jar"/> <code-source path="sjsxp.jar"/> <code-source path="FastInfoset.jar"/> </shared-library> . . .
アプリケーションを構成してJAX-WS RI共有ライブラリをインポートできます。詳細は、「共有ライブラリをインポートするためのアプリケーションの構成」または「すべてのデプロイ済アプリケーションで特定の共有ライブラリをインポートするための構成」を参照してください。
JAX-WS RI共有ライブラリをアプリケーションにインポートする前に、アプリケーションからOracle Web Servicesライブラリをインポート解除する必要があります。手順は、「デフォルトでインポートされるOracle共有ライブラリの削除または置換」を参照してください。
または、アプリケーションのorion-application.xml
デプロイメント・ディスクリプタでアプリケーションへのJAX-WS RI共有ライブラリのインポートを指定して、アプリケーションでJAX-RPC共有ライブラリがインポートされないようにできます。
orion-application.xmlでJAX-WS RI共有ライブラリのインポートを指定する手順:
次のインポート対象ライブラリを使用して、orion-application.xml
ファイル内でアプリケーションのOC4Jデプロイメント・ディスクリプタを作成します。
<orion-application> <imported-shared-libraries> <import-shared-library name="jaxws20" min-version="2.0" max-version="2.0"/> </imported-shared-libraries> </orion-application>
次のように、<remove-inherited>
要素をorion-application.xml
に追加して、アプリケーションでJAX-RPC共有ライブラリがインポートされないようにします。
<?xml version="1.0" encoding="UTF-8"?>
<orion-application>
<imported-shared-libraries>
<remove-inherited name="oracle.ws.jaxrpc"/>
<import-shared-library name="jaxws20"/>
</imported-shared-libraries>
</orion-application>
アプリケーションのEARファイルでorion-application.xml
ファイルをパッケージ化します。