この章の内容は次のとおりです。
デプロイは、アプリケーション・ファイルをアーカイブ・ファイルとしてパッケージ化し、ターゲット・アプリケーション・サーバーに転送するプロセスです。JDeveloperを使用して、JavaまたはJava EEアプリケーションをアプリケーション・サーバー(Oracle WebLogic ServerやIBM WebSphereなど)に直接デプロイすることも、または、アーカイブ・ファイルをデプロイメント・ターゲットにして間接的にデプロイして、そのアーカイブ・ファイルを後からターゲット・サーバーにインストールすることもできます。
アプリケーション開発では、JDeveloperを使用して、統合アプリケーション・サーバーでアプリケーションを実行できます。
拡張機能を使用する場合、製品に固有のデプロイ情報の詳細は、適切な開発者向けガイドを参照してください。たとえば、ADF Fusion Webアプリケーションをデプロイする場合、『Oracle Fusion Middleware Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』のFusion Webアプリケーションのデプロイに関する項を参照してください。
アプリケーションは、次の方法でデプロイできます。
アプリケーション・サーバー接続を介して直接アプリケーション・サーバーにデプロイ。
アーカイブ・ファイルにデプロイ。デプロイメント・ターゲットとしてアーカイブ・ファイルを選択することによって、間接的にアプリケーションをデプロイできます。アーカイブ・ファイルは、ターゲットJava EEアプリケーション・サーバーに後でインストールできます。
JDeveloper統合アプリケーション・サーバーを使用したテスト環境へのデプロイ。Java EEランタイム・サービスで、JDeveloperアプリケーションとプロジェクトをJava EEアプリケーションおよびモジュールとしてJava EEコンテナ内で実行およびテストするために使用します。
注意:
通常、JDeveloperは開発やテストの目的でアプリケーションをデプロイする場合に使用します。アプリケーションを本番用にデプロイする場合は、Enterprise Managerまたはスクリプトを使用して、本番レベルのアプリケーション・サーバーにデプロイできます。
後期テスト環境や本番環境へのデプロイの詳細は、製品固有のデプロイ情報に関する適切な開発者ガイドを参照してください。
図22-1に、デプロイ処理全体を説明したフロー・ダイアグラムを示します。ターゲット・アプリケーション・サーバーをデプロイする準備に関してはこのガイドに記載されていません。サード・パーティ・アプリケーション・サーバーに関する適切なドキュメントを参照してください。
図22-1 デプロイの概要フロー・ダイアグラム
JavaおよびJava EEアプリケーションは、標準化されたモジュール型コンポーネントに基づいており、次のアプリケーション・サーバーにデプロイできます。
Oracle WebLogic Server
Oracle WebLogic Serverは、そうしたモジュール用のサービス一式を備えており、細かいアプリケーション動作の多くを自動的に処理するため、プログラミングは必要ありません。
Oracle Glassfish Server
Oracle GlassFish Serverにデプロイできます
オラクル社以外のベンダーから提供される、次のサード・パーティ・アプリケーション・サーバー
Apache Tomcat
IBM WebSphere
JBoss
GlassFish Server Open Source Edition
JDeveloperと互換性のあるサーバーのバージョンについては、JDeveloperの認定情報(http://www.oracle.com/technetwork/developer-tools/jdev/documentation/index.html)を参照してください。
アプリケーションをOracle Java Cloud Serviceにデプロイすることもできます。詳細は、「Oracle Java Cloud Serviceにデプロイするためのアプリケーションの開発」を参照してください。
JDeveloperを使用して、次の作業を実行できます。
統合アプリケーション・サーバーでのアプリケーションの実行
統合WebLogic Serverを使用してアプリケーションを実行およびデバッグし、その後スタンドアロンのWebLogic Serverまたはサード・パーティのサーバーにデプロイできます。
スタンドアロン・アプリケーション・サーバーへの直接デプロイ
アプリケーションをスタンドアロン・アプリケーション・サーバーに直接デプロイするには、サーバーへの接続を作成し、そのサーバーの名前をデプロイメント・ターゲットとして選択します。
アーカイブ・ファイルへのデプロイ
デプロイメント・ターゲットとしてEARファイルを選択することによって、間接的にアプリケーションをデプロイすることができます。アーカイブ・ファイルは、ターゲット・アプリケーション・サーバーに後でインストールできます。
デプロイは反復プロセスの場合があります。この場合は、アプリケーションに対する調整やデプロイ済アプリケーションの問題の修正のために、テスト・デプロイ環境、アーカイブ・ファイルまたはアプリケーション・サーバーへの再デプロイが必要になります。JDeveloperからアプリケーションをデプロイするプロセスには、多くのプロセスが伴います。
JDeveloperには統合WebLogic Serverと呼ばれる統合アプリケーション・サーバーがバンドルされており、IntegratedWebLogicServer
と呼ばれるデフォルト接続が定義されています。統合アプリケーション・サーバーは、反復的なコード開発サイクルに最適化されたデプロイメントを使用するサービスのためのJava EEランタイムです。JDeveloperアプリケーションおよびプロジェクトを、Java EEコンテナ内のJava EEアプリケーションおよびモジュールとして実行しテストするために、あるいはブラウザやテスターの起動など実行後のサービスのために使用できます。統合アプリケーション・サーバーへの接続は、JDeveloperにデフォルトで用意されているので、デプロイメント・プロファイルやデプロイメント・ディスクリプタは必要ありません。ほとんどの場合、統合アプリケーション・サーバーへのデプロイは1クリックで実行できます。たとえば、「アプリケーション」ウィンドウでWebサービスの右クリック・メニューから「実行」を選択したり、JDeveloperのメイン・メニューから「実行」をクリックします。
アプリケーションのデバッグに使用する機能については、「Javaプロジェクトの実行とデバッグ」を参照してください。
通常、スタンドアロン・サーバーにデプロイするためには、統合アプリケーション・サーバーでアプリケーションを実行してテストと開発を行います。その上で開発モードのスタンドアロンOracle WebLogic Server、またはサード・パーティ・アプリケーション・サーバーにデプロイして、アプリケーションをさらにテストし本番環境を細かくシミュレートします。
一般にJDeveloperでは、次の作業を行って、デプロイに向けてアプリケーションまたはプロジェクトを準備します。
ターゲット・アプリケーション・サーバーへの接続を作成。詳細は、「ターゲット・アプリケーション・サーバーへの接続の作成方法」を参照してください。
デプロイメント・プロファイルを作成(必要な場合)。詳細は、「デプロイメント・プロファイルの作成および編集方法」を参照してください。
デプロイメント・ディスクリプタを作成(必要な場合、およびターゲット・アプリケーション・サーバーに固有の場合)。「デプロイメント依存関係の作成方法と編集方法」を参照してください。
application.xml
とweb.xml
を更新してアプリケーション・サーバーとの互換性を確保(必要な場合)。「デプロイメント・ディスクリプタ・プロパティの表示または変更」を参照してください。
アプリケーションレベルのセキュリティ・ポリシー・データをドメインレベルのセキュリティ・ポリシー・ストアに移行。詳細は、「JDBCデータソースの設定」を参照してください。
アプリケーション・サーバーがすでにインストールされている必要があります。Oracle WebLogic Serverの場合は、Oracle 11g InstallerまたはOracle Fusion Middleware 11g Application Developer Installerを使用してインストールできます。他のアプリケーション・サーバーについては、対象アプリケーション・サーバーのドキュメントの説明に従ってサーバーを取得し、インストールしてください。
データソースへの接続を必要とするアプリケーションのためにグローバルJDBCデータソースを作成して、アプリケーション・サーバーを準備します。
アプリケーションとアプリケーション・サーバーの準備が完了したら、次の作業を行うことができます。
JDeveloperを使用する作業:
デプロイメント・プロファイルとアプリケーション・サーバー接続を使用して、アプリケーション・サーバーに直接デプロイします。
デプロイメント・プロファイルを使用して、EARファイルにデプロイします。
Enterprise Manager、スクリプト、またはアプリケーション・サーバーの管理ツールを使用して、JDeveloperで作成したEARファイルをデプロイします。詳細は、『Oracle Fusion Middleware Oracle ADFアプリケーションの管理』を参照してください。
Oracle Java Cloud Serviceにデプロイするためのアプリケーションの開発は、アプリケーション・サーバーにデプロイするためのアプリケーションの開発と類似しています。
次の操作が必要です。
Oracle Java Cloud Serviceで実行可能なコードでアプリケーションが記述されていることを確認。
Oracle Java Cloud Serviceインスタンスへの接続を作成。
詳細は、次のOracle Java Cloud Service - SaaS拡張機能のアプリケーションの開発を参照してください。
Oracle Cloudサービスの詳細は、http://docs.oracle.com/cloud/latest/index.htmlを参照してください。
Java EEアーカイブ・ファイルには、Java EEモジュールまたはJava EEアプリケーションが含まれています。モジュールは、デプロイ用に構成された、一般的なコンポーネント・タイプの1つ以上のJDeveloperプロジェクトで構成されます。アプリケーションは、1つ以上のモジュールで構成されます。また、アーカイブにはデプロイメント・ディスクリプタも含まれます。デプロイメント・ディスクリプタは、モジュールまたはアプリケーションの構成をサーバーに対して指定するXMLファイルであり、サーバーのタイプに固有です。デプロイメント・ディスクリプタは、サーバー固有の場合もJava EEサーバー汎用の場合もあります。
JAR、EJB JARおよびWARファイルには、それぞれ1つ以上のコンポーネントで構成されるモジュールが含まれます。エンタープライズ・アーカイブ(EARファイル)には、1つ以上のモジュールで構成されるアプリケーションが含まれます。
Webアプリケーション(サーブレット、JSP、JSFおよびADF Faces)またはEJBアプリケーションを作成し、アプリケーション・サーバー接続を介してデプロイする場合、JDeveloperによって、そのアプリケーションがWARまたはEJB JARとしてパッケージ化されます。このWARまたはEJB JARは、オプションでEARファイルにラップできます。アプリケーションが異なるタイプのコンポーネントで構成されている場合、コンポーネントは複数のモジュールにパッケージ化されるため、単独でデプロイするか、EARファイルとしてアセンブルできます。
デプロイメント・プロファイルは、プロジェクトまたはアプリケーションのデプロイを管理するアプリケーションまたはプロジェクトのプロパティです。デプロイメント・プロファイルでは、ソース・ファイル、デプロイメント・ディスクリプタ、およびパッケージ化される他の補助ファイル、作成されるアーカイブ・ファイルのタイプと名前、依存に関する情報、プラットフォーム固有の説明などの情報を指定します。
デプロイメント・ディスクリプタによって、デプロイ済アプリケーションの内容および構成が定義されます。アプリケーションに必要なデプロイメント・ディスクリプタ・ファイルは、アプリケーションに使用されているテクノロジおよびターゲット・アプリケーション・サーバーによって異なります。
デプロイメント・プランを使用すると、web.xml
、weblogic.xml
、application.xml
およびweblogic-application.xml
のアプリケーション・デプロイメント・ディスクリプタで構成を調整できるため、アプリケーションのデプロイ方法を制御できます。
デプロイメント・プランは、plan.xml
というディスクリプタを使用して制御されます。plan.xml
を使用してカスタマイズできるのは、WebLogicのデプロイメント・ディスクリプタ構成のみです。デプロイメントをカスタマイズする主な使用例としては、ベースのWebLogicディスクリプタを変更しないまま、デプロイ先のサーバーごとにWebLogic固有のアプリケーション構成を変更する場合があります。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』のデプロイメント・プランに関する項を参照してください。
JDeveloperのJava Editionを使用している場合は、コアJavaとXMLの機能しか含まれていないため、実行できるデプロイメントが次の操作に限られます。
手動でサーバーにデプロイできる、シンプルJARアーカイブの作成。
JDeveloperのJava Editionには、JARファイルにアプリケーションをパッケージ化する機能があります。Java Editionのデプロイメント・ダイアログでは、JAR名の指定、ファイルのグループ化、または他のデプロイメント・プロファイルへの依存性などの標準JARオプションの限定された構成のみが可能です。さらに構成が必要な任意のアプリケーションでは、JDeveloperのStudio Editionからデプロイする必要があります。
拡張機能を開発する一環としてのデプロイメント・プロファイルの作成。JDeveloper拡張機能の作成の詳細は、『Oracle Fusion Middleware Oracle JDeveloper拡張機能の開発』を参照してください
JDeveloperは、アプリケーションのテストと開発に使用できる統合アプリケーション・サーバーである統合WebLogic Serverとともにインストールされます。開発目的では、統合アプリケーション・サーバーで十分なことがほとんどです。アプリケーションをテストする準備が整ったら、実行ターゲットを選び、メイン・メニューから「実行」コマンドを選択します。
注意:
プロジェクト、ファイル、Webサービスを実行またはデバッグして統合アプリケーション・サーバーを初めて起動すると、デフォルト・ドメイン上の管理者IDのパスワードを入力するダイアログが表示されます。「OK」をクリックすると、デフォルトのドメインが作成されます。この手順は1回のみ実行する必要があります。
アプリケーション・ターゲットを実行すると、プロジェクトとアプリケーションのアーティファクトに基づいて、JDeveloperではデプロイするJava EEモジュールのタイプが自動的に検出されます。次に、JDeveloperではアプリケーションを統合アプリケーション・サーバーにデプロイするためのメモリー内デプロイメント・プロファイルが作成されます。JDeveloperでは、プロジェクトとアプリケーションのファイルは、展開EARディレクトリ構造にコピーされます。このファイル構造は、アプリケーションをEARファイルにデプロイする場合のEARファイル構造を忠実に模したものです。続いて、JDeveloperでは標準のデプロイ手順に従って、展開EARファイルが統合アプリケーション・サーバーに登録およびデプロイされます。展開EAR方式を取ることで、実際のEARファイルのパッケージ化とパッケージ化解除によって生じるパフォーマンス・オーバーヘッドが軽減されます。
要約すれば、実行ターゲットを選択して統合アプリケーション・サーバーでアプリケーションを実行すると、JDeveloperによって次のことが行われます。
プロジェクトとアプリケーションのアーティファクトに基づいて、デプロイするJava EEモジュールのタイプを検出
メモリーにデフォルトの(つまりカスタマイズされていない)デプロイメント・プロファイルを作成
プロジェクトとアプリケーションのファイルを、アプリケーションの展開EARファイルをシミュレートしたファイル構造を持つ作業ディレクトリにコピー
模擬EARを統合アプリケーション・サーバーに登録およびデプロイするためのデプロイ・タスクを実行
アイデンティティ、資格証明およびポリシーを自動的に移行。スタンドアロンのOracle WebLogic Serverインスタンスにアプリケーションをデプロイする予定がある場合は、このセキュリティ情報の移行が必要になります。
注意:
統合アプリケーション・サーバーでアプリケーションを実行するときには、JDeveloperではアプリケーション用に作成されたデプロイメント・プロファイルは無視されます。
アプリケーションは、統合アプリケーション・サーバーの基本ドメインで実行されます。基本ドメインは、スタンドアロンのOracle WebLogic Serverインスタンスの基本ドメインと同じ構成になっています。つまり、この基本ドメインは、構成ウィザードを使用して、スタンドアロンのOracle WebLogic Serverインスタンスにデフォルト・オプションで基本ドメインを作成した場合と同一です。
JDeveloperでは、JDeveloperテクノロジ拡張に基づいて、この基本ドメインが必要なドメイン拡張テンプレートで拡張されます。たとえば、JDeveloper Studioをインストールした場合、JDeveloperでは統合アプリケーション・サーバー環境がADFランタイム・テンプレート(JRF Fusion Middlewareランタイム・ドメイン拡張テンプレート)で自動的に構成されます。
「アプリケーション・サーバー・プロパティ」ダイアログを使用して、アプリケーションが使用するポートを編集できます。ただし、1024より小さいポート番号は指定できません。この設定は、「アプリケーション・サーバー・プロパティ」ダイアログの「構成」ページにあります。アプリケーション・サーバー・ナビゲータを開き、IntegratedWebLogicServerを右クリックして「プロパティ」を選択し、「構成」タブをクリックして、「優先ポート」フィールドに、希望するポート番号(1024以上)を入力します。
デフォルト・ドメインを使用するのみでなく、アプリケーションの実行とテストに使用できる追加のデフォルト・ドメインを、統合アプリケーション・サーバーに明示的に作成できます。「アプリケーション・サーバー」ウィンドウを開き、IntegratedWebLogicServerを右クリックして、「デフォルト・ドメインの作成」を選択します。
統合アプリケーション・サーバーでアプリケーションを実行またはデバッグするときに生成される出力メッセージは、「実行中: IntegratedWebLogicServer」または「デバッグ中: IntegratedWebLogicServer」というタイトルのログ・ウィンドウに表示されます。
統合WebLogic Serverの「ログ」ウィンドウには、次の内容が表示されます。
サーバーと、そのサーバーで実行されているアプリケーションに関するステータス・ログ・メッセージ
統合アプリケーション・サーバー・インスタンスのコンソールからの出力(色付き)
アプリケーションを統合アプリケーション・サーバーにデプロイするとき生成されるメッセージ
Java EEアーカイブ(EAR、WAR、EJB JAR)の作成中に記録されるメッセージ。ログ・ウィンドウのリンクをクリックすると、生成されたアーカイブを参照できます。
生成されたログ・ファイルは、jdeveloper-user-home/DefaultDomain/server/DefaultServer/logs
にあります。
診断ログのパラメータは、logging.xml
ファイルで構成できます。一時ロガーは、サーバーがデバッグ・モードで実行されている間にのみ追加できます。
weblogic.xml
のjsp-descriptor
要素およびlogging
要素で-verbose
要素を使用すれば、ログ・ファイルに送信する情報のレベルを制御できます。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』で、weblogic.xmlのディスクリプタ要素に関する情報を参照してください。
統合アプリケーション・サーバーへのデプロイでは、デフォルト・マッピングのプロジェクト・メタデータに依存するデフォルトのデプロイメント・プロファイルが使用されます。プロファイルのデフォルト要素はプロジェクトの依存性によって決まり、依存性には次のような規則があります。
プロジェクトAがプロジェクトBのビルド出力に依存する場合、プロジェクトBのビルド出力はプロジェクトAにマージされます。プロジェクトAがWebアプリケーションの場合は、プロジェクトAとプロジェクトBのビルド出力がどちらも、生成されるWARのWEB-INF/classes
にコピーされることになります。
マージされるということは、特定のURIのコピーが1つしか存在できないことを意味します。WEB-INF/classes
に1つしか存在しないからです。
プロジェクトAがプロジェクトBのデプロイメント・プロファイル、たとえばJARプロファイルに依存する場合、そのデプロイメント・プロファイルは最終的に、生成されるWARのWEB-INF/lib
に含まれます。
WEB-INF/web.xml
を含むプロジェクトはWebプロジェクトとして認識され、デフォルトのWARプロファイルが作成されます。
少なくとも1つのセッションEJB Beanを含むプロジェクトはEJBプロジェクトとして認識され、デフォルトのEJB JARプロファイルが作成されます。
Webプロジェクト用に「デフォルトでデプロイ済」とマークされるすべてのライブラリは、Webアプリケーション・ライブラリとして(WARのWEB-INF/lib
に)デプロイされます。
EJBプロジェクト用に「デフォルトでデプロイ済」とマークされるすべてのライブラリは、アプリケーション・ライブラリとして(EARのlib
に)デプロイされます。
EJBプロジェクトAがプロジェクトBのビルド出力に依存する場合、プロジェクトBのビルド出力(classes
など)はプロジェクトAのビルド出力にマージされ、EJB JARのルート・ディレクトリにデプロイされます。
JDeveloperおよびご使用のコンピュータ・システムとインスタンスとの相互作用は、統合アプリケーション・サーバーの定義によって制御されます。
JDeveloperには統合WebLogic Serverと呼ばれる統合アプリケーション・サーバーがバンドルされており、IntegratedWebLogicServer
と呼ばれるデフォルト・インスタンスが定義されています。すべてのアプリケーションは、デフォルトでIntegratedWebLogicServer
にバインドされています。
アプリケーションがバインドされる統合アプリケーション・サーバーは、そのプロパティを変更できます。
注意:
統合アプリケーション・サーバーとして使用されるWebLogic Serverドメインは、JDeveloperプロセスと同じホスト上に配置される必要があります。
アプリケーションがバインドされる統合アプリケーション・サーバーのプロパティを変更するには、次のようにします。
統合アプリケーション・サーバーの新規インスタンスを作成できます。
統合アプリケーション・サーバー接続を定義するには、次のようにします。
デフォルトでは、EJB、サーブレット、HTML、Webサービス、またはJSPプロジェクトを実行またはデバッグするとき統合アプリケーション・サーバーが自動的に起動します。あるいは、「実行」メニューから「サーバー・インスタンスの起動」または「サーバー・インスタンスのデバッグ」をクリックして統合アプリケーション・サーバーを起動することもできます。
起動した統合アプリケーション・サーバーは、Java EEアプリケーションの実行を停止しても自動的には停止しません。したがって、JSPやサーブレットなどのオブジェクトを「アプリケーション」ウィンドウで選択して、「実行」メニューからオプションを選択できます。
ワーキング・セットを実行またはデバッグできます。ワーキング・セットとはファイルのグループであり、「実行」メニューの「現在のワーキング・セットを使用(Java EEのみ)」オプションを選択し、名前付きフィルタをプロジェクトに適用することによって作成されます。
ワーキング・セットを有効にした場合、ソース・エディタのポップアップ・メニューまたは「アプリケーション」ウィンドウのノードから、「実行」または「デバッグ」を選択した際に、これが実行またはデバッグされる現在のワーキング・セットとなります。
一度に実行できる統合アプリケーション・サーバーは1つのみです。したがって、サーバーの別のインスタンスを起動しようとすると、JDeveloperでは前のインスタンスがシャットダウンされ、「アプリケーション」ウィンドウで選択したアイコンの要求タスクを実行するために、インスタンスが再起動されます。統合アプリケーション・サーバーの起動後は、複数のアプリケーションを相互に独立して実行できます。アプリケーションの実行中にそのアプリケーションを再実行すると、最新バージョンのアプリケーションが再デプロイされます。
統合アプリケーション・サーバーで実行するアプリケーションは、サーバー・インスタンスにバインドされている必要があります。JDeveloperにはWebLogicサーバー・ドメインが付属しており、DefaultServer
という名前のデフォルト・サーバー・インスタンスが定義されています。この統合アプリケーション・サーバーに対して定義される一意の統合アプリケーション・サーバー接続はIntegratedWebLogicServer
と呼ばれ、システム・ディレクトリ$SYSTEM_ROOT/DefaultDomain
として定義されるドメイン・ホームを持っています。すべてのアプリケーションは、デフォルトでIntegratedWebLogicServer
にバインドされています。
統合アプリケーション・サーバーのデフォルト・ドメインを明示的に作成していない場合には、アプリケーションを実行またはデバッグしてサーバーを起動するとき、デフォルト設定で自動的に起動します。
あるいは、「アプリケーション・サーバー」ウィンドウで明示的にデフォルト・ドメインを作成することもできます。
必要な場合は、作成しなおして新しい値を使用するように、既存のデフォルト・ドメインを削除できます。
統合アプリケーション・サーバーのデフォルト・ドメインを明示的に作成するには、次のようにします。
必要な場合は、「ウィンドウ」→「アプリケーション・サーバー」を選択して「アプリケーション・サーバー」ウィンドウを開きます。
統合アプリケーション・サーバー接続「IntegratedWebLogicServer」
を右クリックし、「デフォルト・ドメインの作成」を選択します。「デフォルト・ドメインの構成」ダイアログが開いたら、デフォルトをそのまま使用するか、別のリスニング・アドレスを選択するなど、明示的に別の値を設定します。詳細は、「デフォルト・ドメインの構成」ダイアログで「ヘルプ」をクリックするか、[F1]を押してください。
JDeveloperに拡張機能をインストールする際には、統合アプリケーション・サーバーのデフォルト・ドメインの更新が必要になる場合があります。
統合アプリケーション・サーバーのデフォルト・ドメインを更新するには、次のようにします。
「IntegratedWebLogicServer」
を右クリックし、「デフォルト・ドメインの更新」を選択します。デフォルト・ドメインがすでに作成されており、特定の設定を使用する必要がある場合には、既存のデフォルト・ドメインを削除して作成しなおすことができます。
JDeveloperを閉じたまま統合されたアプリケーション・サーバーのデフォルト・ドメインを削除するには、ファイル・システムでシステム・フォルダを探し、削除します。JDeveloperを再起動すると、統合アプリケーション・サーバーの新しいデフォルト・ドメインを作成できるようになります。
サーバーの起動後に、「ウィンドウ」メニューから「プロセス」を選択すると、統合アプリケーション・サーバーのプロセスが表示されます。
注意:
実行モードのサーバーでは同時に複数のアプリケーションを実行できますが、デバッグ・モードで一度にデバッグできるアプリケーションは1つのみです。JDeveloperを非デバッグの編集モードに戻すには、統合アプリケーション・サーバーを停止する必要があります。
アプリケーションを統合アプリケーション・サーバーで実行して、テストできます。ブレークポイントを設定し、統合アプリケーション・サーバーでデバッグ・モードでアプリケーションを実行することもできます。実行とデバッグの詳細は、「Javaプロジェクトの実行とデバッグ」を参照してください。
統合アプリケーション・サーバーでアプリケーションを実行するには、次のようにします。
「アプリケーション」ウィンドウで実行ターゲット、たとえばプロジェクト、Webサービス、バインドなしタスク・フロー、JSFページなどを選択します。
実行ターゲットを右クリックして、「実行」または「デバッグ」を選択します。あるいは、メイン・メニューから「実行」または「デバッグ」を選択します。
アプリケーションを実行またはデバッグして統合アプリケーション・サーバーを初めて起動すると、デフォルト・ドメイン上のデフォルト・ユーザーweblogic
のパスワードを入力するダイアログが表示されます。「OK」をクリックすると、デフォルトのドメインが作成されます。この手順は1回のみ実行する必要があります。
アプリケーション・レベルのデータソースとグローバルなデータソース
統合アプリケーション・サーバーにデプロイする場合は、アプリケーション・レベルのデータソースまたはグローバル・データソースを使用できます。
統合アプリケーションへの1クリックによるデプロイの場合、JDeveloperでは、アプリケーション・リソース名を識別するために、Webアプリケーションweb.xml
またはEJBアプリケーションejb-jar.xml
に必要な<resource-ref>
エントリが含まれていることが確認されます。名前の形式はjdbc/connection-nameDS
で、connection-name
はアプリケーション・リソースの名前です。
アプリケーションでは、java:comp/env/jdbc/connection-nameDS
のアプリケーション固有のリソースJNDIネームスペースを使用してこのデータソースを参照します。アプリケーションでこのリソースを検出できるのは、web.xml
にjdbc/connection-nameDS
の<resource-ref>
エントリが含まれているためです。
統合WebLogic Serverへの1クリックによるデプロイでアプリケーション・レベルのデータソースを使用するには、「アプリケーション・プロパティ」ダイアログ(「アプリケーション」メニューから選択可能)の「WebLogic」ページで「JDeveloperでアプリケーションを実行する際にJDBC接続を自動生成」を選択します。これにより、次の処理が実行されます。
アプリケーションのEARファイルの/META-INFディレクトリに、connection-name-jdbc.xml
というファイルが生成されます。
このJDBCモジュールを参照するMETA-INFのweblogic-application.xml
ファイルに、対応する<module>
エントリが作成されます。
アプリケーションで、アプリケーション・リソースのデータベース接続が複数使用されている場合は、データベース接続ごとにconnection-name-jdbc.xml
ファイルが作成され、weblogic-application.xml
ファイルの<module>
エントリ数は同じになります。
統合WebLogic Serverへの1クリックによるデプロイでグローバル・データソースを使用するには、「アプリケーション・プロパティ」ダイアログ(「アプリケーション」メニューから選択可能)の「WebLogic」ページで「JDeveloperでアプリケーションを実行する際にJDBC接続を自動生成」の選択を解除し、次のようにします。
統合WebLogic Server管理コンソールに接続します。「統合WebLogic Server管理コンソールへのログイン方法」を参照してください。
Oracle WebLogic Serverで作成するときと類似の方法で、グローバル・データソースを作成します。「JDBCデータソースの設定」を参照してください。
デフォルトでは、EJB、サーブレット、またはJSPプロジェクトを実行またはデバッグするとき統合アプリケーション・サーバーが自動的に起動します。したがって、JSPやサーブレットなどのオブジェクトを「アプリケーション」ウィンドウで選択して、「実行」メニューからオプションを選択できます。
注意:
プロジェクト、ファイル、Webサービスを実行またはデバッグして統合アプリケーション・サーバーを初めて起動すると、デフォルト・ドメイン上の管理者IDのパスワードを入力するダイアログが表示されます。「OK」をクリックすると、デフォルトのドメインが作成されます。この手順は1回のみ実行する必要があります。
一度に実行できる統合アプリケーション・サーバーは1つのみです。したがって、サーバーの別のインスタンスを起動しようとすると、JDeveloperでは前のインスタンスがシャットダウンされ、「アプリケーション」ウィンドウで選択したアイコンの要求タスクを実行するために、インスタンスが再起動されます。
サーバーの起動後に、「プロセス」ウィンドウを開くと、統合アプリケーション・サーバーのプロセスが表示されます。「プロセス」ウィンドウは、メイン・メニューから「ウィンドウ」→「プロセス」を選択すると開きます。
統合アプリケーション・サーバーを起動するには、次のようにします。
必要な場合は、「ウィンドウ」→「アプリケーション・サーバー」を選択して「アプリケーション・サーバー」ウィンドウを開きます。
統合WebLogic Server接続を右クリックし、「サーバー・インスタンスの起動」を選択します。
あるいは、メイン・メニューから「実行」→「サーバー・インスタンスの起動」を選択します。
デバッグ・モードで統合アプリケーション・サーバーを起動するには、次のようにします。
あるいは、メイン・メニューから「実行」→「サーバー・インスタンスのデバッグ」を選択します。
統合アプリケーション・サーバーで大きいアプリケーションを実行している場合、デプロイが完了する前に取り消すことができます。
実行中のデプロイメントを取り消すには、「ログ」ウィンドウで「終了」ボタンをクリックし、取り消すプロファイルまたはアプリケーションを選択します。
統合アプリケーション・サーバーを起動すると、統合アプリケーション・サーバーのプロセスが「プロセス」ウィンドウに表示されます。詳細は、「プロセス・ウィンドウの理解」を参照してください。
「プロセス」ウィンドウは、メイン・メニューから「ウィンドウ」→「プロセス」を選択すると開きます。
注意:
統合アプリケーション・サーバーにデプロイされたアプリケーションは、統合アプリケーション・サーバーを終了するとき自動的にアンデプロイされます。
デフォルトの動作では、すべてのアプリケーションがアンデプロイされますが、この動作は変更できます。
実行中の統合アプリケーション・サーバーを停止するには、次のいずれかを実行します。
メイン・メニューから「実行」→「終了」→「IntegratedWebLogicServer」(または統合アプリケーション・サーバーの接続名)を選択します。
ツールバーの「終了」ドロップダウン・リストから統合アプリケーション・サーバー名を選択します。
メイン・メニューから「ウィンドウ」→「プロセス」を選択します。統合アプリケーション・サーバー名を右クリックし、「終了」を選択します。
「ファイル」→「終了」を選択してJDeveloperを終了します。インスタンスのプロセスを終了するように要求された場合は、「はい」をクリックします。
「アプリケーション・サーバー」ウィンドウで統合アプリケーション・サーバー接続を右クリックし、「サーバー・インスタンスの終了」を選択します。
統合WebLogic Serverを強制的に停止するには、次のようにします。
統合WebLogic Serverを強制的に停止するに必要がある場合には、「終了」ボタンを2回押してください。
統合アプリケーション・サーバー接続に対して、起動と停止の動作を構成できます。
統合アプリケーション・サーバーの起動と停止の動作を構成するには、次のようにします。
統合アプリケーション・サーバーはOracle WebLogic Serverの実装であり、サーバーの管理コンソールに接続できます。
注意:
管理コンソールにログインするには、次のような方法でJDeveloperから統合アプリケーション・サーバーを実行している必要があります。
「アプリケーション・サーバー」ウィンドウで統合WebLogic Serverを起動。
アプリケーションを起動。
統合アプリケーション・サーバーの管理コンソールを起動してログインするには、次のようにします。
統合アプリケーション・サーバーはOracle WebLogic Serverの実装なので、統合アプリケーション・サーバーの管理コンソールについては、JDeveloperのインストールにあるWebLogic Serverのオンライン・ドキュメントから、または管理コンソールから利用できる管理コンソール・オンライン・ヘルプを参照してください。
アプリケーションをスタンドアロンのアプリケーション・サーバーにデプロイする前に、JDeveloperで必須のタスクを実行し、デプロイに向けてアプリケーションを準備する必要があります。
図22-2に、アプリケーションをデプロイ用に準備する場合のプロセス・フローを示します。アプリケーションを作成し、アプリケーション・サーバーの準備が終わると、アプリケーションをデプロイできるようになります。
図22-2 アプリケーションのデプロイ用の準備のフロー・ダイアグラム
JDeveloperアプリケーション・サーバー接続を介して、アプリケーション・サーバーにアプリケーションをデプロイできます。
この項では、アプリケーション・サーバーへの接続を作成する一般的な方法について説明します。特定のタイプのアプリケーション・サーバーへの接続の詳細は、「特定のアプリケーション・サーバー・タイプへの接続」を参照してください。
始める前に:
アプリケーション・サーバーがインストールされ、起動していることを確認します。
プロキシ・サーバーの内部で作業している場合は、JDeveloperが使用しているプロキシ設定の確認が必要な場合があります。
「ツール」→「プリファレンス」を選択して「プリファレンス」ダイアログを開き、「Webブラウザとプロキシ」ページにナビゲートします。詳細を参照するには、「設定」ダイアログの「Webブラウザとプロキシ」ページで、[F1]を押すか「ヘルプ」をクリックします。
「プロキシ設定」タブにJDeveloperが使用しているプロキシ設定が表示され、必要に応じて変更できます。デフォルトでは、JDeveloperはシステムのデフォルトのプロキシ設定を使用しています。これらをオーバーライドするには、「プロキシなし」、「自動構成スクリプトの使用」または「手動プロキシ設定」を選択して、設定を適宜入力します。「プロキシ設定の構成」を参照してください。
アプリケーション・サーバーへの接続の作成方法:
次のいずれかの方法で、「アプリケーション・サーバー接続」ウィザードを起動します。
「アプリケーション・サーバー」ウィンドウで、「アプリケーション・サーバー」を右クリックして、「新規アプリケーション・サーバー」を選択します。
「新規ギャラリ」で、「一般」を展開し、「接続」→「アプリケーション・サーバー接続」を選択して、「OK」をクリックします。
「リソース」ウィンドウで、「新規」→「接続の作成」→「アプリケーション・サーバー」を選択します。
ウィザードの「使用方法」ページが表示されたら、「スタンドアロン・サーバー」が選択されていることを確認し、「次へ」をクリックします。
「名前とタイプ」ページで、新しい接続の名前を入力します。
「接続タイプ」ドロップダウン・リストで、接続を作成するアプリケーション・サーバーのタイプを選択します。オプションは次のとおりです。
Oracle WebLogic Serverへの接続を作成する場合は「WebLogic 10.3」または「WebLogic 12.x」
Oracle GlassFish ServerまたはGlassFish Open Source Editionへの接続を作成する場合は「GlassFish 3.1」
JBossへの接続を作成する場合は「JBoss 5.x」
Tomcatへの接続を作成する場合は「Tomcat 7.x」
IBM WebSphere Serverへの接続を作成する場合は「WebSphere Server 8.x」
Oracle Java Cloud Serviceへの接続を作成する場合は「Oracle Cloud」
「次へ」をクリックします。
「認証」ページで、アプリケーション・サーバーへのアクセスを認可された管理ユーザーのユーザー名とパスワードを入力します。
「次へ」をクリックします。
「構成」ページで、アプリケーション・サーバーへの接続を作成するパラメータを入力します。
「次へ」をクリックします。
WebSphereを選択した場合は、表示される「JMX」ページにSOAアプリケーションのデプロイに必要なJMX構成値を入力します。
「次へ」をクリックします。
テスト・ページで、「接続のテスト」をクリックして、接続をテストします。
JDeveloperにより、数種類の接続テストが実行されます。アプリケーションをデプロイできるためには、JSR-88テストに合格する必要があります。テストに不合格だった場合は、ウィザードの前のページに戻って、構成を修正します。
「終了」をクリックします。
Oracle WebLogic Server管理コンソールの起動方法
Oracle WebLogic Server管理コンソールは「アプリケーション・サーバー」ウィンドウから起動および接続できます。
注意:
コンソールにログインするには、サーバーが起動している必要があります。
「アプリケーション・サーバー」ウィンドウでOracle WebLogic Serverインスタンスへの接続の名前を右クリックし、「管理コンソールの起動」を選択します。ブラウザ・インスタンスでログイン・ページ(http://host:port/console
)が開きます。
たとえば、デフォルト構成を使用する場合、ブラウザはhttp://localhost:7001/console
を使用します。
Oracle WebLogic Serverインスタンスへの接続を最初に作成したときに使用したユーザー名とパスワードを使用してログインします。統合WebLogic Serverの管理コンソールを起動する場合、デフォルト・ユーザーはweblogic
、パスワードはデフォルト・ドメインを作成したときに入力したパスワードです。
WebLogic Server管理コンソールの詳細は、JDeveloperのインストールにあるWebLogic Serverのオンライン・ドキュメントから、または管理コンソールから利用できる管理コンソール・オンライン・ヘルプを参照してください。
この項では、様々なタイプのアプリケーション・サーバーに関する固有の情報を示します。
JDeveloperではサーバー・クラスタへのデプロイがサポートされていますが、JDeveloperを使用して、クラスタのメンバーである個々の管理対象サーバーにデプロイすることはできません。
Oracle WebLogic Serverに接続するには:
Oracle WebLogicホスト名は、アプリケーション(.jar、.war、.ear、.gar
)がデプロイされるTCP/IP DNSを含む、WebLogic Serverインスタンスの名前です。
「ポート」フィールドに、アプリケーション(.jar、.war、.ear、.gar
)がデプロイされるOracle WebLogic Serverインスタンスのポート番号を入力します。
ポートを指定しない場合、ポート番号はデフォルトの7001になります。
「SSLポート」フィールドに、アプリケーション(.jar、.war、.ear、.gar
)がデプロイされるOracle WebLogic ServerインスタンスのSSLポート番号を入力します。
SSLポートの指定はオプションです。デプロイメント時に確実にセキュア接続にする場合にのみ必要です。
ポートを指定しない場合、SSLポート番号はデフォルトの7002になります。
SSLポートを使用してOracle WebLogic Serverインスタンスに接続するために、「常にSSLを使用」を選択します。
オプションで、Oracle WebLogic Serverが管理権限のないサーバー・ノードを名前で識別するように構成されている場合のみ、WebLogicドメインを入力します。
GlassFishサーバーに対するセキュアな接続を作成する場合は、「構成」ページの「ホスト名」に、IPアドレスではなく、localhost
などのホスト名を使用する必要があります。そうしないと接続に失敗します。これは、サーバーへの接続の作成に使用されるURL内のホスト名が、証明書のホスト名と一致する必要があるためです。
JBossの場合:
JBossデプロイ・ディレクトリの位置を入力するか参照します。ここにアプリケーション・ファイル(.jar、.war、.ear、.gar
)があります。
JMXを使用している場合は、「この接続のJMXの有効化」を選択します(オプション)。
注意:
JMXの構成はオプションで、JBoss Application Serverへの接続には必要ありません。JMXはSOAアプリケーションのデプロイにのみ必要です。
JBossサーバーでは、Oracle JMX RMIコネクタ(oracle-jboss-remoting.sar
)を使用する必要があります。標準のJBoss JMXコネクタ(jmx-remoting.sar
)はJDeveloperで機能しません。
「ホスト名」フィールドに、ターゲット・サーバーのホスト名を入力します。デフォルトはマシン名です。
「RMIポート」フィールドに、JBossのRMI接続ポートのポート番号を入力します。デフォルトは19000です。
WebSphereの場合:
「ホスト名」フィールドに、Java EEアプリケーション(.jar
、.war
、.ear
、[.gar])がデプロイされる、TCP/IP DNSを含むWebSphereサーバーの名前を入力します。名前を入力しない場合は、デフォルトのlocalhost
になります。
「SOAPコネクタのポート」フィールドに、ポート番号を入力します。このホスト名とポートが、デプロイ用にサーバーへの接続に使用されます。デフォルトのSOAP接続ポートは8879
です。
「サーバー名」フィールドに、この接続のターゲット・アプリケーション・サーバーに割り当てられた名前を入力します。
「ターゲット・ノード」フィールドに、この接続のターゲット・ノード名を入力します。ノードとは、管理対象サーバーのグループです。デフォルトはmachineNode01
で、この場合のmachineはノードが常駐するマシンの名前です。
「ターゲット・セル」フィールドに、この接続のターゲット・セルの名前を入力します。セルとは、ランタイム・コンポーネントをホストするプロセスのグループです。デフォルトはmachineNode01Cell
で、この場合のmachineはノードが常駐するマシンの名前です。
「WS管理スクリプト・ファイルの場所」フィールドに、IBM WebSphereアプリケーション・サーバー接続のシステム・ログイン構成を定義するために使用するwsadminスクリプト・ファイルの場所を入力するか、参照して指定します。ORACLE_HOME/oracle_common/common/bin
ディレクトリにあるwsadminファイルは正しいバージョンではないため、使用できません。デフォルトの場所は、Unix/Linuxの場合はwebsphere-home/bin/wsadmin.sh
、Windowsの場合はwebsphere-home/bin/wsadmin.bat
です。
注意:
スクリプト・ファイルを指定する場合、パスに空白が含まれていると問題が生じることがあります。たとえば、C:\Program Files (x86)\IBM\WebSphere\AppServer\profiles\AppSrv01\bin\wsadmin.bat
の場合、この問題を解決するには、名前に空白があるディレクトリに対してOS短縮名(Progra~1など)を使用するか、空白のないパスにWebSphereアプリケーション・サーバー・インスタンスを作成し、その場所でバッチ・ファイルを参照します。
WebSphereを選択した場合は、「JMX」ページが表示されます。「JMX」ページで、JMXの情報を入力します(オプション)。
注意:
JMXの構成はオプションで、WebSphere Application Serverへの接続には必要ありません。JMXはSOAアプリケーションのデプロイにのみ必要です。
「この接続のJMXの有効化」を選択してJMXを有効にします。
「RMIポート」フィールドに、WebSphereのRMI接続ポートのポート番号を入力します。デフォルトは2809です。
「WebSphereランタイムJARの場所」フィールドに、WebSphereランタイムJARの場所を入力するか、参照して指定します。
「WebSphereプロパティの場所(セキュアなMBeanアクセス用)」フィールドに、セキュリティ構成および有効なMBeanのプロパティを含むファイルの場所を入力するか、参照して指定します。このフィールドはオプションです。
Oracle Java Cloud Serviceにサインアップすると、Oracle Java Cloud Serviceインスタンスへの接続を確立するために使用するデータ・センター、アイデンティティ・ドメインおよびサービス名に関する情報を受信します。
Oracle Java Cloud Serviceに接続するには、次の情報を入力する必要があります。
「認証」ページで、管理ユーザー名とパスワードを入力します。
「構成」ページで、データ・センターを選択し、Oracle Java Cloud Serviceインスタンスのアイデンティティ・ドメインとサービス名を入力します。
デプロイメント・プロファイルでは、ターゲット環境にデプロイされるアーカイブにアプリケーションがパッケージ化される方法が定義されています。デプロイメント・プロファイル:
作成されるアーカイブ・ファイルのフォーマットと内容を指定します。
パッケージ対象となるソース・ファイル、デプロイメント・ディスクリプタ、およびその他の補助ファイルをリストします。
作成されるアーカイブ・ファイルのタイプおよび名前を記述します。
依存情報、プラットフォーム固有の指示、およびその他の情報を示します。
アプリケーション・サーバーへのデプロイでは、デフォルト・マッピングのプロジェクト・メタデータに依存するデプロイメント・プロファイルが使用されます。プロファイルのデフォルト要素はプロジェクトの依存性によって決まりますが、デプロイメント・プロファイルをカスタマイズして変更できます。
依存性を決定する規則は、次のとおりです。
プロジェクトAがプロジェクトBのビルド出力に依存する場合、プロジェクトBのビルド出力はプロジェクトAにマージされます。プロジェクトAがWebアプリケーションの場合は、プロジェクトAとプロジェクトBのビルド出力がどちらも、生成されるWARのWEB-INF/classes
にコピーされることになります。
マージされるということは、特定のURIのコピーが1つしか存在できないことを意味します。WEB-INF/classes
に1つしか存在しないからです。
プロジェクトAがプロジェクトBのデプロイメント・プロファイル、たとえばJARプロファイルに依存する場合、そのデプロイメント・プロファイルは最終的に、生成されるWARのWEB-INF/lib
に含まれます。
Webプロジェクト用に「デフォルトでデプロイ済」とマークされるすべてのライブラリは、Webアプリケーション・ライブラリとして(WARのWEB-INF/lib
に)デプロイされます。
EJBプロジェクト用に「デフォルトでデプロイ済」とマークされるすべてのライブラリは、アプリケーション・ライブラリとして(EARのlib
に)デプロイされます。
アプリケーション・レベルで「デフォルトでデプロイ」とマークされるすべてのライブラリは、アプリケーション・ライブラリとして(EARのlib
に)デプロイされます。
EJBプロジェクトAがプロジェクトBのビルド出力に依存する場合、プロジェクトBのビルド出力(classesディレクトリなど)はプロジェクトAのビルド出力にマージされ、EJB JARのルート・ディレクトリにデプロイされます。
アプリケーション・レベルのデプロイメント・プロファイルは、次のとおりです。
EARファイル: Java EEエンタープライズ・アーカイブ(EAR)ファイルとしてデプロイする場合に使用します。EARファイルは、アプリケーションのアセンブルされたWARファイル、EJB JARファイルおよびクライアントJARファイルで構成されます。
MARファイル: シード・カスタマイズに対してメタデータ・アーカイブ・ファイルをデプロイする、またはアプリケーション・サーバーのMDSリポジトリにベース・メタデータをデプロイする場合に使用します。MARファイルの詳細は、使用している製品に該当する開発者ガイドを参照してください。
プロジェクト・レベルのJava EEデプロイメント・プロファイルは、次のとおりです。
ビジネス・コンポーネント・アーカイブ: ADF Business Componentsをデプロイするためのシンプル・アーカイブ・ファイルを作成します。
ビジネス・コンポーネントのサービス・インタフェース: ADF Business Componentsをサービス・インタフェースとしてデプロイするためのプロファイルを作成します。
クライアントJARファイル: 標準のJava EEクライアントJARファイルをデプロイする場合に使用します。
EJB JARファイル: Java EE EJBモジュール(EJB JAR)をデプロイする場合に使用します。EJB JARには、EJBコンポーネントとそれに対応するデプロイメント・ディスクリプタが含まれます。
拡張機能JAR: 拡張機能をJARファイルとしてデプロイするためのプロファイルを作成します。
JARファイル: プロジェクトからシンプルJARアーカイブを作成します。
GARファイル: Oracle Coherenceグリッド・アーカイブ・ファイルを作成します。GARには、Coherenceアプリケーションのアーティファクトが格納され、デプロイメント・ディスクリプタが含まれています。
MOFモデル・ライブラリ: あるプロジェクトのUMLオブジェクトを他のプロジェクトで再使用できるようにするMOF (メタオブジェクト機能)モデル・ライブラリJARファイルを作成します。
OSGiバンドル: OSGiコンテナとしてデプロイできるOSGiバンドルを作成します。JDeveloperで拡張機能を作成するとき、これを使用します。
RARファイル: Java EEコネクタのRARファイルをデプロイするためのプロファイルを作成します。
共有ライブラリJARファイル: シンプル・アーカイブをデプロイするためのプロファイルを作成します。これはファイル・システムのJARまたはZIPファイル、またはリモート・サーバーの共有ライブラリです。
Taglib JARファイル: カスタム・タグ・ライブラリをJARファイルとしてデプロイするためのプロファイルを作成します。
WARファイル: Java EE Webモジュール(WAR)をデプロイする場合に使用します。WARは、Webコンポーネント(JSPやサーブレット)と、それに対応するデプロイメント・ディスクリプタで構成されます。
デプロイメント・プロファイルを作成するには、アプリケーションまたはプロジェクトを選択し、「ファイル」→「新規」→「ギャラリから」を選択して、「一般」カテゴリから「デプロイメント・プロファイル」を選択します。アプリケーション・レベルのプロファイルを作成するには、アプリケーション・レベルで「新規ギャラリ」を起動します。
他の方法を使用して、デプロイメント・ファイルを作成できます。
「アプリケーション・プロパティ」の「デプロイメント」ダイアログの使用:
JDeveloperのツールバーから、「アプリケーション」→「デプロイ」→「新規デプロイメント・プロファイル」を選択します
アプリケーションを右クリックして、コンテキスト・メニューから「デプロイ」→「新規デプロイメント・プロファイル」を選択します。
「アプリケーション」ウィンドウで、「アプリケーション」ウィンドウのツールバーのドロップダウン・リストを開き、「デプロイ」を選択します。
「プロジェクト・プロパティ」の「デプロイメント」ダイアログの使用:
「アプリケーション」ウィンドウでプロジェクトを選択し、メニューから「アプリケーション」→「プロジェクト・プロパティ」を選択します。「デプロイメント」を選択し、右側の「デプロイメント」パネルで、メニュー・バーから「新規プロファイル」アイコンをクリックします。
「アプリケーション」ウィンドウのプロジェクトのポップアップ・メニュー。
既存のデプロイメント・プロファイルを変更するには:
「アプリケーション」ウィンドウでプロジェクトを右クリックして「プロジェクト・プロパティ」を選択し、ウィザードのツリー構造から「デプロイメント」を選択します。次に、デプロイメント・プロファイルを選択し、「編集」を選択します。
「アプリケーション」ウィンドウでアプリケーションを右クリックして「アプリケーション・プロパティ」を選択し、ウィザードのツリー構造から「デプロイメント」を選択します。次に、デプロイメント・プロファイルを選択し、「編集」を選択します。
プロファイル・デプロイメントをアクティブにするには:
プロジェクト・レベルのデプロイメント・プロファイルの場合は、「アプリケーション」ウィンドウでプロジェクトを右クリックし、「デプロイ」→デプロイメント・プロファイルを選択します。
アプリケーションのデプロイメント・プロファイルの場合は、「アプリケーション」ウィンドウでアプリケーションを右クリックし、「デプロイ」→デプロイメント・プロファイルを選択します。あるいは、次のようにします
「アプリケーション」ウィンドウでアプリケーションを右クリックし、「デプロイ」→デプロイメント・プロファイルを選択します。
アプリケーションのコンテキスト・メニューから「デプロイ」→デプロイメント・プロファイルを選択します。
「アプリケーション」ウィンドウのツールバーのドロップダウン・リストから「デプロイ」→デプロイメント・プロファイルを選択します。
プロジェクトおよびそのプロジェクトが依存するプロジェクトがコンパイルされ、パッケージ化されます。
作成したアプリケーションには、必要なデプロイメント・プロファイルがすでに含まれている場合があります。たとえば、Webベースのプロジェクトを作成する場合、必要な依存モデル・プロジェクトを含むデフォルトのWARデプロイメント・プロファイルがすでに存在します。
デプロイメント・プロファイルを作成するには:
デプロイメント・プロファイルは、アプリケーション・レベルのデプロイメント・プロファイルであれば「アプリケーションのプロパティ」ダイアログから、プロジェクト・レベルのデプロイメント・プロファイルであれば「プロジェクト・プロパティ」ダイアログから使用でき、それぞれ編集または削除できます。
デプロイメント・プロファイルを作成したら、そのプロパティを表示および変更できます。
デプロイメント・プロファイルを編集または削除するには、次のようにします。
構成は、コンポーネント・ファイルからアーカイブ・ファイルをアセンブルするプロセスです。構成は、「デプロイメント・プロファイルのプロパティ」ダイアログの「ファイル・グループ」
ブランチで指定します。
「ファイル・グループ」
ブランチはファイル・グループのリストで構成され、各グループでコンポーネントを指定します。パッケージ化されたアーカイブは、すべてのファイル・グループを統合したものです。ファイル・グループの順序によって名前の競合が解決されます。2つのファイルに同じ名前が付けられている場合、リストの上位のファイル・グループ内のファイルが含められ、下位のファイル・グループ内のファイルが省略されます。
新規に作成されたデプロイメント・プロファイルには、1つ以上の事前定義済ファイル・グループが含まれます。ファイル・グループは追加、削除および編集できます。
ファイル・グループは、一連のフィルタで抽出されたソース元によって定義されます。ソース元はソース・ファイル、JARファイルおよびそれらを含めるために選択されたディレクトリです。フィルタは、ソース元またはソース元のコンポーネントのサブディレクトリおよびファイルに適用される規則であり、パッケージ化するセットおよびファイルを識別します。ファイル・グループには、次の3つの種類があります。
「パッケージ化」ファイル・グループ・タイプでは、ソース元、プロジェクト・ディレクトリなどのディレクトリ、JARファイルおよびフィルタを選択できます。このファイル・グループは柔軟で透過的なメカニズムであり、ほとんどのプロジェクトに適しています。
「ライブラリ」ファイル・グループ・タイプでは、プロジェクト・ライブラリであるソース元を選択できます。ライブラリ・ファイル・グループは、WARデプロイメント・プロファイルに対して作成されます。ライブラリ・ファイル・グループは、既存のJARファイルを再パッケージ化する必要があるプロジェクトに役立ちます。
アプリケーションのコンポーネント間でのデプロイメントの依存性は、プロジェクトのデプロイメント・プロファイルに指定されます。プロジェクトのデプロイメント・プロファイルに、直接のアップストリームであるプロジェクトのプロファイルを指定します。デプロイメント・プロファイルがデプロイメント用にアクティブになっている場合、その依存性が最初にデプロイされます。
デプロイメント・プロファイルの「プロファイルの依存性」ページで、デプロイメント・プロファイル依存性を設定します。現在のアプリケーション内のデプロイメント・プロファイルのみが選択用にリストされます。詳細は、「ヘルプ」をクリックしてください。次のようなプロファイル依存性を選択できます。
プロファイルとプロファイルの依存性
プロファイルとJARの依存性
プロファイルとWARの依存性
プロファイルとRAR(リソース・アーカイブ)の依存性
あるプロジェクトに含まれているプロファイルをデプロイするとき、そのプロジェクトが他のプロファイルについてプロファイルとプロファイルの依存性を持っている場合、そのプロファイルは、プロジェクトで指定されている依存性をデプロイ時に組み込みます。たとえば、Project1.jpr
ファイルにServlet1.java
が含まれ、そのファイルがejb1.jar
に依存し、project2.jpr
ファイルにMySessionEJB
とejb1.jar
が含まれている場合は、最初のプロジェクトをデプロイすると、EARファイルにwebapp1.war
とejb1.jar
の両方が含まれます。
共通JARファイルを共有するJAR、WAR、EJB JARモジュール間のプロファイル依存性を作成するときは、META-INF/MANIFEST.MF Class-Path
属性を使用して、デプロイ時にまとめてJARファイルをリンクできます。「デプロイメント・プロファイルのプロパティ」の「JARオプション」ページで、「manifestファイルを含める(META-INF/MANIFEST.MF)」を選択します。これによって、共通JARの1つの共有コピーが、EARファイルに組み込まれます。
依存プロジェクトには独自の依存性を指定できますが、循環依存を回避する必要があります。JDeveloperで循環依存が発生した場合、デプロイは試行されますが、ログ・ウィンドウに警告が表示されます。
依存ライブラリとは、モジュールのコンパイルと実行に必要とされるライブラリです。ライブラリを含むプロジェクトの「プロジェクト・プロパティ」ダイアログの「ライブラリとクラスパス」ページで、依存ライブラリはエクスポート可能として表示されます。
アプリケーションでは、次のプロジェクトに依存ライブラリを配置できます。
現在のモジュールのプロファイルのプロジェクト。これはプロファイル・コンテナです。
プロファイル・コンテナが依存するプロジェクト。
このモジュールのプロファイルについて、プロファイルの依存性に関連付けられているプロジェクト(そのプロファイルとプロジェクトの依存性に対して再帰的に)。
プロジェクトの依存性(左側に矢印)とプロファイルの依存性(右側に矢印)の例を次に示します。
図22-3 プロジェクトとデプロイメント・プロファイルの間の依存性
プロジェクトの依存性は、コンパイル時に再帰的でなくてもデプロイ時に再帰的です。JavaProject
からのライブラリが依存ライブラリとみなされるのはそのためです。WebProfile
はWebモジュールを表し、次の依存性ライブラリがあります。
EjbDepLib
(WebProject
に対するプロジェクトの依存性からのライブラリ)
EjbDep.jar
(WebProject
に対するプロジェクトの依存性からのライブラリ)
JavaDepLib
(JavaProject
に対する再帰的なプロジェクトの依存性からのライブラリ)
JavaDep.jar
(JavaProject
に対する再帰的なプロジェクトの依存性からのライブラリJAR)
SampleLib
(プロファイルの依存性からのライブラリ)
Sample.jar
(プロファイルの依存性からのライブラリJAR)
OtherLib
(再帰的なプロファイルの依存性からのライブラリ)
Other.jar
(再帰的なプロファイルの依存性からのライブラリJAR)
依存ライブラリは、解決済と未解決のいずれかの状態になります。依存ライブラリは、アーカイブに追加されてクラスパスに配置されるまで未解決とみなされ、追加と配置が済むと、そのライブラリを参照する必要があるクラスでライブラリの内容を使用できるようになります。
たとえばWARプロファイルがライブラリを解決する場合は、WEB-INF\lib
というターゲット出力ディレクトリを持つライブラリ・ファイル・グループ要素でそのライブラリを選択します。こうすると、作成されるWARアーカイブには、そのアーカイブのWEB-INF\lib
ディレクトリのライブラリが含まれ、WARアーカイブのクラスパスにライブラリの内容が含まれるようになります。
ライブラリがデプロイメント・プロファイルによって解決されない場合、このプロファイルは未解決のライブラリをアプリケーション階層に公開し、上位レベルで解決できるようにします。EJBプロジェクトに含まれるライブラリが、EJBプロファイルのパースペクティブから解決されないままになる状況を考えます。この情報は、このようなライブラリが、EARレベルで(EARプロファイルのライブラリ・ファイル・グループで)確実にEARプロファイルによって解決されるように公開されます。
前述の図で、WebProjectにはJavaProjectに対するプロジェクトの依存性があり、JavaProjectにはJavaDepLib
と呼ばれるライブラリが含まれます。WebProjectにWARデプロイメント・プロファイルを作成するWebアプリケーションを定義できます。WARデプロイメント・プロファイルのWEB-INF\lib
ライブラリ・ファイル・グループでライブラリを確実に選択することによって、WebモジュールでJavaDepLib
が解決されます。
デプロイメント・ディスクリプタは、アプリケーションのデプロイ構成を定義するサーバー構成ファイルで、必要に応じてJava EEアプリケーションとともにデプロイされます。プロジェクトに必要なデプロイメント・ディスクリプタは、プロジェクトが使用しているテクノロジとターゲット・アプリケーション・サーバーのタイプによって異なります。デプロイメント・ディスクリプタは、ソース・ファイルとして作成および編集できるXMLファイルですが、JDeveloperは、ほとんどのディスクリプタ・タイプについて、プロパティの表示と設定に使用できるダイアログまたは概要エディタを備えています。これらのファイルが宣言的に編集できない場合、JDeveloperではソース・エディタでXMLファイルが開き、内容を編集できるようになります。
標準のJava EEデプロイメント・ディスクリプタ(application.xml
およびweb.xml
など)に加えて、ターゲット・アプリケーション・サーバーに固有のデプロイメント・ディスクリプタも使用できます。たとえば、Oracle WebLogic Serverにデプロイする場合、weblogic.xml
、weblogic-application.xml
およびweblogic-ejb-jar.xml
を使用できます。
基本ディスクリプタは、デプロイメント・プロファイルを作成するウィザードで作成します。デフォルトの動作をオーバーライドする場合にのみ他のディスクリプタを追加します。作成したディスクリプタをデプロイ時にアーカイブ・ファイルに含める場合もあります。
デプロイメント・ディスクリプタは、「新規ギャラリ」で作成することもできます。デプロイメント・ディスクリプタは、プロジェクトのアプリケーション・ソースのMETA-INFサブフォルダ、またはWebコンテンツ・フォルダのWEB-INFサブフォルダに配置されます。
Java EE標準デプロイメント・ディスクリプタは、それぞれ対応するOracle WebLogic Server固有のディスクリプタによって拡張されます。表22-1は、これらのファイルについて説明し、互いの関係を示しています。
表22-1 デプロイメント・ディスクリプタ
Java EE標準ディスクリプタ | Oracle WebLogic Server固有のディスクリプタ |
---|---|
アーカイブとしてデプロイされたJava EEアプリケーションのクライアントで使用されるEJBモジュールと他のリソースを記述します。 |
ファイル形式は、 詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverスタンドアロン・クライアントの開発』のクライアント・アプリケーション・デプロイメント・ディスクリプタ要素に関する章を参照してください。 |
EJBモジュールやWebモジュールなど、Java EEアプリケーションのコンポーネントを指定します。アプリケーションの追加構成を指定することもできます。このディスクリプタは、アプリケーションのEARファイルの/META-INFディレクトリに含める必要があります。 |
ファイル形式は、 詳細は、Oracle Fusion Middleware Oracle WebLogic Server XMLアプリケーションの開発を参照してください。 |
JAR内のEnterprise JavaBeansの特定の構造特性および依存性を定義し、Beanがコンテナとの相互作用をどのように実行するかに関する指示をEJBコンテナに提供します。 |
このファイルの形式は、
EJB 3.x モジュールの場合。このファイルの形式は、 詳細は、『Oracle Fusion Middleware Oracle WebLogic Server Enterprise JavaBeansの開発』を参照してください。
|
RARファイルにパッケージ化されたリソース・アダプタの実装コード、構成プロパティおよびセキュリティ設定に関する情報が含まれています。 |
このファイルの形式は、 詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverリソース・アダプタの開発』を参照してください。 |
静的ページ、サーブレット、JSPページなど、Java EE Webコンポーネント・セットを指定して構成します。また、Webコンポーネントがコールする可能性のあるEJBなどの他のコンポーネントも指定して構成します。複数のWebコンポーネントで独立したWebアプリケーションを形成し、スタンドアロンWARファイルでデプロイできます。 |
このファイルの形式は、 詳細は、Oracle Fusion Middleware Oracle WebLogic Server XMLアプリケーションの開発を参照してください。 |
なし。 |
デプロイ済アプリケーションで使用されるデータソースを定義します。 このファイルの形式は、 詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCデータ・ソースの管理』を参照してください。
このファイルの形式は、 名前/値ペアのリストと、アプリケーションの様々なデプロイメント・ディスクリプタの説明が含まれます。管理者はこれを使用して、デプロイメント・ディスクリプタの値をオーバーライドできます。 詳細は、Oracle Fusion Middleware Deploying Applications to Oracle WebLogic Serverを参照してください。
このファイルの形式は、 診断アプリケーション・モジュールで診断監視を作成または変更する際に、WebLogic Server管理コンソールで使用されます。 詳細は、Oracle Application Server 10gリリース・ノートfor AIX Based Systemsを参照してください。
このファイルの形式は、 Oracle WebLogic ServerでJMSドライバを構成する際に使用されます。 詳細は、Oracle Fusion Middleware Oracle WebLogic Server JMSアプリケーションの開発を参照してください。
このファイルの形式は、 詳細は、『Oracle Fusion Middleware Oracle WebLogic Server WebLogic Webサービス・リファレンス』を参照してください。 |
必要なデプロイメント・ディスクリプタの多くは、JDeveloperで自動的に作成されます。必要なデプロイメント・ディスクリプタが存在しない場合や、追加のディスクリプタを作成する必要がある場合は、明示的な作成が可能です。
始める前に:
JDeveloperでは、デプロイメント・ディスクリプタがすでに生成されているかどうかを確認します。
デプロイメント・ディスクリプタの作成方法:
「アプリケーション」ウィンドウで、ディスクリプタを作成するプロジェクトを右クリックし、「新規」を選択します。
「新規ギャラリ」で、「一般」を展開し、「デプロイメント・ディスクリプタ」、ディスクリプタ・タイプの順に選択して、「OK」をクリックします。
目的の項目が見つからない場合は、正しいプロジェクトが選択されていることを確認してから「すべての機能」タブを選択するか、「検索」フィールドを使用してディスクリプタを検索します。項目が有効になっていない場合は、そのタイプのディスクリプタがプロジェクトにまだ存在しないことを確認します。1つのプロジェクトで使用できるディスクリプタのインスタンスは1つのみです。
「デプロイメント・ディスクリプタの作成」ウィザードが起動し、選択したデプロイメント・ディスクリプタのタイプに応じて、JDeveloperでは概要エディタまたはソース・エディタでファイルが開きます。
注意:
EARファイルの場合は、1つのアプリケーションに、どのような種類であっても複数のデプロイメント・ディスクリプタを作成しないでください。実行時には、アプリケーション・リソースのディスクリプタ、またはEARレベルで生成されたディスクリプタのみが使用されます。アプリケーションの複数のプロジェクトが同じデプロイメント・ディスクリプタを使用すると、起動されたプロジェクトに属するディスクリプタが他のディスクリプタより優先されます。この制約は、application.xml
、weblogic-jdbc.xml
、jazn-data.xml
およびweblogic.xml
に適用されます。
アプリケーションレベルのディスクリプタの作成に最適な場所は、「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルの「ディスクリプタ」ノードです。アプリケーションは、確実に、正しいディスクリプタとともに作成されます。
デプロイメント・ディスクリプタのプロパティを確認または変更するには、次の手順を実行します。
次の手順に従って、Webサービス・ポリシー参照を作成します。
「webservice-policy-ref.xml」
を選択します。左側のタブを使用すると、ポリシー参照名、ポート・ポリシーおよび操作ポリシーを個別に編集できます。ウィザードには、設定ごとに「概要」、「ソース」、「履歴」の各ビューが表示されます。オンライン・ヘルプを参照してください。
「プリファレンス」ダイアログの「デプロイメント」ページでグローバル・デプロイメント・オプションを設定できます。
デプロイメント設定を構成するには、次の手順を実行します。
注意:
アプリケーション固有およびプロジェクト固有のデプロイメント・プロファイル・オプションは、アプリケーション・プロパティまたはプロジェクト・プロパティから設定してください。「アプリケーション・プロパティ」および「プロジェクト・プロパティ」ダイアログは「アプリケーション」メニューにあります。
この項では、アプリケーションを正常にアプリケーション・サーバーにデプロイするために実行する必要があるタスクについて説明します。
JDeveloperでアプリケーションを作成する際には、アプリケーション・サーバー接続を介して、パッケージ化されたアプリケーションをOracle WebLogic Serverにデプロイできます。パッケージ化されたアプリケーションには、デプロイするファイルの指定、それらのファイルの構成の説明、およびターゲット・サーバーの指定を行うデプロイメント・プロファイルが含まれます。ターゲットのOracle WebLogic Serverインスタンスは、ローカルでインストールするか、ネットワーク・ドライブにマップする必要があります。
Oracle WebLogic Serverへのデプロイのためにアプリケーションを構成するには、次のようにします。
Java EEクライアント・モジュールは、クライアントJARファイルとしてパッケージ化されます。このファイルには、1つ以上のJavaアプリケーション・コンポーネント、および1つのクライアント・デプロイメント・ディスクリプタ・ファイル(application-client.xml
)が含まれています。デプロイメント・プロファイルとデプロイメント・ディスクリプタ・ファイルを作成した後は、クライアントJARをアプリケーション・サーバーにデプロイできます。
クライアント・アプリケーションをデプロイ用にパッケージ化するには、次の手順を実行します。
スタンドアロン・アプレットは、Webアーカイブ(WAR)ファイルとしてパッケージ化されます。このファイルには、そのアプレット、アプレットHTMLファイル、標準のJava EE Webデプロイメント・ディスクリプタweb.xml、および場合によっては、ターゲット固有のデプロイメント・ディスクリプタも含まれています。デプロイメント・プロファイルと適切なデプロイメント・ディスクリプタ・ファイルを作成した後は、アプリケーションを、アプリケーション・サーバーにデプロイしたり、アーカイブ・ファイルとしてデプロイすることができます。
Webアプリケーションをデプロイ用に構成するには、次の手順を実行します。
注意:
「クラスが見つかりません」
というエラーが表示されるなど、Swingアプレット(JApplet)をデプロイしているときに問題が発生した場合は、JDeveloperがSwingライブラリを検出できないことを示している可能性があります。場合によっては、クライアントでSunのJava SEブラウザ・プラグインを使用するか、JVMバージョン1.1のSwingライブラリをアプレットにバンドルする必要があります。デプロイされるアプレット・ファイルは、デプロイ済の他のWebアプリケーション・ファイルとは別の場所に配置する必要があります。
デプロイされたファイルにパスワードがプレーン・テキストで表示されるのを避けるため、JDeveloperではパスワードのインダイレクションが使用されます。したがって、アプリケーションが正常に実行されるためには、データソースのパスワードをサーバー上で設定する必要があります。
これを行うにはグローバル・データソースを使用し、グローバル・データソースはOracle WebLogic Server管理コンソールで「JDBC」の下にある「データソース」リンクを使用して設定します。
JDeveloperでは、アプリケーション・リソース名を識別するために、Webアプリケーションweb.xml
またはEJBアプリケーションejb-jar.xml
に必要な<resource-ref>
エントリが含まれていることが確認されます。名前の形式はjdbc/connection-nameDS
で、connection-nameはアプリケーション・リソース接続の名前です。
アプリケーションでは、java:comp/env/jdbc/connection-nameDS
のアプリケーション固有のリソースJNDIネームスペースを使用してこのデータソースを参照します。アプリケーションでこのリソースを検出できるのは、web.xml
にjdbc/connection-nameDS
の<resource-ref>
エントリが含まれているためです。
生成されるファイルにとって重要なコントロールは、「アプリケーション・プロパティ」ダイアログの「WebLogic」ページにある「デプロイ中にweblogic-jdbc.xmlディスクリプタを自動生成および同期化」フィールドです。
「自動生成」フィールドを選択すると、JDeveloperでは次の動作が行われます。
アプリケーション・リソースの接続ごとにapplication-name-jdbc.xml
ファイルを生成し、間接的なパスワード属性を設定します。
<jdbc-driver-params> <use-password-indirection>true</use-password-indirection> </jdbc-driver-params>
デプロイ時に、JDeveloperではJDBC接続のパスワードはapplication-name-jdbc.xml
のユーザー名から決定され、Mbeanを使用してJDBC接続パスワードが移入されます。
weblogic-application.xml
が更新され、各application-name-jdbc.xml
がモジュールとして追加されます。
web.xml
(存在する場合)には、各JDBC JNDI名へのリソース参照があります。
Oracle WebLogic Serverでグローバル・データソースを作成する方法
グローバル・データソースは、Oracle WebLogic Server管理コンソールで作成します。
グローバル・データソースを設定するには、次のようにします。
例22-1 Oracle WebLogic Serverで実行するためのEARファイルへのデプロイ
Oracle WebLogic Serverで実行するアプリケーションをEARファイルにデプロイする場合、次の操作を実行できます。
「デプロイ中にweblogic-jdbc.xmlディスクリプタを自動生成および同期化」フィールドを選択し、アプリケーション・レベルの資格証明マッピングを使用してパスワードを設定します。
あるいは、「デプロイ中にweblogic-jdbc.xmlディスクリプタを自動生成および同期化」フィールドの選択を解除し、Oracle WebLogic Serverでグローバル・データソースを作成してパスワードを設定します。
ojdeploy
を使用してデプロイを行う場合
-nodatasources
スイッチを使用し、次のいずれかの方法でOracle WebLogic Server上でパスワードを設定できます。
グローバル・データソースの作成。
アプリケーション・レベルのデータソースの手動作成。
ojdeployの詳細は、「コマンドラインからのデプロイ」を参照してください。
-nodatasources
スイッチを使用しない場合は、アプリケーション・レベルの資格証明マッピングを使用する方法でのみパスワードを設定できます。
アプリケーションをサード・パーティのサーバーで実行するために必要な、固有のタスクがあります。
Tomcatへのデプロイ:
デプロイ後にTomcatサーバーを停止し、再起動します。
jdeveloper_install/jdk/lib
に格納されているtools.jar
ライブラリが、Tomcatクラスパスにあることを確認します。このファイルは、Tomcatの実行に使用されるJDKと同じバージョンの必要があります。そうでない場合は、Tomcatでアプリケーションを実行するときに問題が発生することがあります。
Webアプリケーションはtomcat_install/webapps
/サブディレクトリにデプロイすることをお薦めします。このオプションは、「WARファイル」デプロイメント・プロファイルの一般ページで設定します。
Tomcatアプリケーション・サーバーのシステム管理者は、conf/server.xml
ファイルでアプリケーションへのコンテキスト・パスを割り当てる必要があります。
<DefaultContext crossContext="true"/>
詳細は、Tomcatのシステム管理ドキュメントを参照してください。
TomcatにデプロイしたJSPアプリケーションを実行すると、次のエラー・メッセージが表示される場合があります。
Only one of the two parameters ... or ... should be defined.
Tomcatではプール後にタグがリリースされないため、定義されている互換性のない属性を同じタグに引き続き使用すると、このようなエラーが発生します。
エラーの発生を避けるには、Tomcatでのタグのプーリングを無効化する必要があります。
テキスト・エディタで、tomcat_home/conf/web.xml
ファイルを開きます。
次の要素を検索します。
<init-param> <param-name>enablePooling</param-name> <param-value>true</param-value> </init-param>
<param-value>
の値をfalseに変更します。
WebSphereへのデプロイ
JDeveloperで生成されたEARを含むディレクトリに空白があると、WindowsへのWebSphereのデプロイは機能しません。
コマンドライン・オプションを渡すためにターゲット・アプリケーション・サーバー接続に直接アクセスできます。たとえば、RMI-IIOPデプロイメントをサポートするために、必要なスタブとスケルトンをクライアント側に含むクライアントJARを指定できます。これらのオプションは、サーバーのデフォルト設定を上書き(つまり無視)します。
デプロイ時にターゲット・アプリケーション・サーバー接続にオプションを渡すには、次の手順を実行します。
まだ作成していない場合は、適切なデプロイメント・プロファイルを作成します。
「アプリケーション」ウィンドウで、プロジェクトを右クリックして「プロパティ」を選択します。
「プロジェクト・プロパティ」ダイアログの左側のパネルで、「デプロイメント」を選択します。
編集するデプロイメント・プロファイルを選択し、「編集」をクリックします。
コマンド・オプションを渡すターゲット接続タイプに対応したページが開きます。
ページを編集するか、または「デフォルトに戻す」をクリックしてターゲット・サーバーのデフォルト設定に戻します。
詳細は、「ヘルプ」をクリックしてください。
「デプロイメント・プロファイルのプロパティ」の編集が終了したら、「OK」をクリックします。
デプロイメント・プランを使用すると、デプロイメントの値をオーバーライドできます。これを行う理由の1つは、テストを終了したアプリケーションを本番環境で実行できるように、デプロイメント・プロファイルを変更せずに設定を変更することです。
デプロイメント・プランを使用するように構成されているEAR、WARまたはEJB JARアーカイブをデプロイすると、アーカイブとデプロイメント・プランの両方がアプリケーション・サーバーに送信されます。1つのアプリケーションで複数のデプロイメント・プランを使用できます。
詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』の「製品デプロイ用のアプリケーションの構成」のデプロイメント・プランに関する項を参照してください。
application.ear
というEARのデプロイメント・プランの例を次に示します。module-name
要素には、関連付けるデプロイメント・プロファイルの名前が含まれている必要があります。
<deployment-plan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.oracle.com/technology/weblogic/10.3/deployment-plan http://www.oracle.com/technology/weblogic/10.3/deployment-plan/1.0/deployment-plan.xsd" xmlns="http://www.oracle.com/technology/weblogic/10.3/deployment-plan"> <application-name>DeployPlan</application-name> <variable-definition> <variable> <name>SessionDescriptor_timeoutSecs</name> <value>888</value> </variable> <variable> <name>SessionDescriptor_invalidationIntervalSecs</name> <value>888</value> </variable> <variable> <name>SessionDescriptor_cookieMaxAgeSecs</name> <value>888</value> </variable> </variable-definition> <module-override> <module-name>application.ear</module-name> <module-type>ear</module-type> <module-descriptor external="false"> <root-element>weblogic-application</root-element> <uri>META-INF/weblogic-application.xml</uri> <variable-assignment> <name>SessionDescriptor_timeoutSecs</name> <xpath>/weblogic-application/session-descriptor/timeout-secs</xpath> </variable-assignment> <variable-assignment> <name>SessionDescriptor_invalidationIntervalSecs</name> <xpath>/weblogic-application/session-descriptor/invalidation-interval-secs</xpath> </variable-assignment> <variable-assignment> <name>SessionDescriptor_cookieMaxAgeSecs</name> <xpath>/weblogic-application/session-descriptor/cookie-max-age-secs</xpath> </variable-assignment> </module-descriptor> </module-override> </deployment-plan>
デプロイメント・プランを使用するように構成されているEAR、WARまたはEJB JARアーカイブをデプロイすると、アーカイブとデプロイメント・プランの両方がアプリケーション・サーバーに送信されます。1つのアプリケーションで複数のデプロイメント・プランを使用できます。
新規ギャラリからデプロイメント・プランを作成し、XMLエディタで編集できます。
作成したデプロイメント・プランは、EAR、WARまたはEJB JARに関連付けることができます。
または、Oracle WebLogic Serverでデプロイメント・プランを生成し、JDeveloperで使用する方法もあります。
デプロイ・プランを作成するには、次のようにします。
デプロイメント・プランを使用すると、アプリケーションのデプロイメント構成を複数のWebLogic Server環境にエクスポートできます。
デプロイメント・プランは、JDeveloperで最初から作成できます。
または、この項で説明しているように、デプロイメント・プランを生成してJDeveloperでアプリケーションに追加し、目的に合せて編集できます。これを行うには、次の2つの方法があります。
アプリケーションをOracle WebLogic Serverにデプロイし、管理コンソールを使用してアプリケーションに変更を加えて、生成されたデプロイメント・プランを保存します。次に、デプロイメント・プランをJDeveloperでソースにコピーし戻し、必要な場合には変更できます。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』の「製品デプロイ用のアプリケーションの構成」のデプロイメント・プランに関する項を参照してください。
weblogic.PlanGeneratorコマンドライン・ツールを使用し、EARを使用するアプリケーションにデプロイメント・プランを生成します。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』の「weblogic.PlanGeneratorコマンドライン・ツール」を参照してください。
WebLogic Server管理コンソールを使用してデプロイメント・プランを生成するには、次のようにします。
Oracle WebLogic Serverにアプリケーションをデプロイします。
WebLogic Server管理コンソールを開きます。
ドメインにインストールしたアプリケーションのデプロイメント・プロパティを対話的に変更すると、WebLogic Server管理コンソールは、有効なデプロイメント・プランを自動的に生成(または更新)します。生成されたデプロイメント・プランを後のデプロイメントにおけるアプリケーションの構成に使用することもできますし、デプロイメント・プロパティを繰返し編集および保存することで新しいバージョンのデプロイメント・プランを生成することもできます。
weblogic.PlanGeneratorコマンドライン・ツールを使用してデプロイメント・プランを生成するには、次のようにします。
JDeveloperは、様々なアプリケーション・サーバーに対する、様々なテクノロジを含むアプリケーションのデプロイをサポートしています。この項では、アプリケーションをファイル・システム上の実行可能JARファイルにデプロイする手順について説明します。Java EEテクノロジを含むアプリケーションをデプロイする場合や、統合アプリケーション・サーバー、Oracle WebLogic Server、またはサポート対象の他のアプリケーション・サーバーにデプロイする場合は、「アプリケーション・サーバーへのJava EEアプリケーションの接続とデプロイ」に示す必須の構成および準備手順を完了していることを確認してください。
アプリケーションは、アーカイブ・ファイルをデプロイメント・ターゲットとして選択することで、間接的にデプロイできます。アーカイブ・ファイルは、ターゲットJava EEアプリケーション・サーバーに後でインストールできます。
JDeveloperには、異なるアプリケーションに対する様々なデプロイメント・モードがあります。ただし場合によっては、アプリケーションをJARファイルとしてファイル・システムに迅速かつ簡単にデプロイすることが必要になります。
注意:
実行可能なJARファイルをデプロイするためには、デプロイメント・プロファイルをあらかじめ作成しておく必要があります。
JDeveloperでシンプル・アーカイブをデプロイするには、次の手順を実行します。
「アプリケーション」ウィンドウでプロジェクトを選択して右クリックします。
「デプロイメント・プロファイルのデプロイ」を選択します。デプロイメント・プロファイルは、前に作成したデプロイメント・プロファイルです。
「デプロイ」ダイアログの「デプロイメント・アクション」ページで「JARファイルにデプロイ」を選択し、ウィザードを終了します。
シンプル・アーカイブまたはJava EEクライアント・モジュールを実行可能JARファイルにすると、javaコマンドを使用して起動できます。
注意:
実行可能なJARファイルをデプロイするためには、デプロイメント・プロファイルをあらかじめ作成しておく必要があります。
実行可能JARファイルをデプロイするには、次の手順を実行します。
アプリケーションはOSGiバンドルとしてデプロイでき、それをOSGiコンテナにデプロイできます。
JDeveloperには、異なるアプリケーションに対する様々なデプロイメント・モードがあります。ただし場合によっては、アプリケーションをJARファイルとしてファイル・システムに迅速かつ簡単にデプロイすることが必要になります。
注意:
OSGiバンドルをデプロイするには、デプロイメント・プロファイルをあらかじめ作成しておく必要があります。詳細は、「デプロイメント・プロファイルの作成および編集方法」を参照してください。
JDeveloperでOSGiバンドルをデプロイするには、次のようにします。
Java EEアプリケーションは、JDeveloperを使用してスタンドアロン・アプリケーション・サーバーに直接デプロイすることも、アーカイブ・ファイルを作成し、他のツールを使用してアプリケーション・サーバーにデプロイすることもできます。
Java EEエンタープライズ・アーカイブ(EAR)デプロイメント・プロファイルを使用すると、アプリケーション・アセンブリの処理を集中管理できます。このアセンブル・タスクでは、EARファイルに組み込む構成済のJava EEデプロイメント・プロファイルを選択します。構成済のWAR、EJB JARまたはクライアントJARのプロファイルは、同じアプリケーション内のプロジェクトとして任意に組み合せることができます。アプリケーションを任意のアプリケーション・サーバー接続にデプロイする場合、JDeveloperでは、プロファイルの組合せを含む最小限のEARファイルがアセンブルされ、ターゲット・アプリケーション・サーバーにデプロイされます。
アプリケーションをJava EEエンタープライズ・アーカイブ(EARファイル)としてデプロイするには、次の手順を実行します。
EARデプロイメント・プロファイルを後から開きなおして変更を加えるには、「アプリケーション」ウィンドウのツールバーでアプリケーションを右クリックし、「アプリケーション・プロパティ」を選択します。次に、「アプリケーション・プロパティ」ダイアログの「デプロイメント」セクションでプロファイルの名前を選択し、「編集」をクリックします。
既存のEARファイルがある場合は、JDeveloper EARインポート機能を使用してEARを任意のプロジェクトにインポートできます。
EARファイルに含めるJARファイル、WARファイルおよびGARファイルは、EARファイルのデプロイ前に作成されている必要があります。これらの従属するアーカイブを作成するには、含まれるアプリケーションのデプロイメント・ディスクリプタに対して、「デプロイ」ダイアログで「JARファイルにデプロイ」、「GARにデプロイ」または「WARファイルへデプロイ」を選択します。
EARファイルにはパスワードが含まれていないため、たとえばEARファイルを作成してOracle WebLogic Serverで実行する場合、データソースをサーバー上で設定する必要があります。
リソース・アダプタ・アーカイブ(RAR)ファイルに格納されているリソース・アダプタは、Java EEアプリケーションのEARファイルと同様に、すべてのJava EEサーバーにデプロイできます。RARファイルは、EARファイルに含めるか、個別ファイルとして存在させることができます。
JDeveloperでリソース・アダプタ・アーカイブをデプロイするには、次の手順を実行します。
JDeveloperプロジェクトでは、EARプロファイルは、リソース・アダプタ・アーカイブ・ファイル(RARまたは.rar
)をサポートしています。通常、RARファイルは、JDBCドライバのようにEnterprise Intelligence Server (EIS)ベンダーによって提供されます。Java EE開発者は、RARがサポートするEISサービスを自分のJava EEアプリケーションで利用する場合、RARファイルを自分のEARファイルにパッケージする必要があります。JDeveloperでは、RARファイルの作成を直接サポートしていませんが、JARファイル・デプロイメント・プロファイルのファイル・グループ機能を使用してRARファイルをアセンブルすることはできます。
ra.xml
ファイルは、J2EE Connector Architecture (JCA)対応のRARファイルのデプロイメント・ディスクリプタです。詳細は、次を参照してください。
http://www.oracle.com/technetwork/java/javaee/tech/entapps-138775.html
RARをEARデプロイメント・プロファイルに追加するには、次の手順を実行します。
.rar
)ファイルの隣にあるチェック・ボックスをチェックします。 デプロイ時に、EARファイルのapplication.xmlには、RARファイルに自動的に追加される<connector>要素が含まれています。
メタデータ・アーカイブ(MAR)プロファイルは、アプリケーション・レベルのデプロイメント・プロファイルで、シード・カスタマイズをパッケージ化したり、ベース・メタデータをMDSリポジトリに配置するために使用します。MARプロファイルでは、ファイル・レベルではなくパッケージ・レベルでのみ選択が行えます。
MARプロファイルには、2つの使用方法があります。
1つ目の使用方法は、MARプロファイルを作成することです。作成したプロファイルは、デプロイのためにアプリケーションのEARに含めることができます。
2つ目の使用方法は、リモート・サーバーにデプロイされるアプリケーション用に構成されたMDSリポジトリにMARの内容をエクスポートすることです。この手順は、ADFライブラリのカスタマイズ変更を、リモート・アプリケーション・サーバーのデプロイ済アプリケーションに適用するためのものです。カスタマイズを初めてMARにパッケージ化し、最終的にEARの一部とするための手順ではありません。
詳細は、『Oracle Fusion Middleware Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』でカスタマイズされたアプリケーションをパッケージおよびデプロイする方法に関する項を参照してください。
アプレットを含むWebアプリケーション・コンポーネントは、WARファイルまたはEARファイルとしてターゲット・アプリケーション・サーバーにデプロイできます。
アプレットをWARファイルとしてデプロイするには、次の手順を実行します。
デプロイしたWebアプリケーションは、ブラウザを実行してテストできます。詳細は、「アプリケーションのテストとデプロイの検証」を参照してください。
「クラスが見つかりません」というエラーが表示されるなど、Swingアプレット(JApplet)をデプロイしているときに問題が発生した場合は、JDeveloperがSwingライブラリを検出できないことを示している可能性があります。場合によっては、クライアントでSunのJava SEブラウザ・プラグインを使用するか、JVMバージョン1.1のSwingライブラリをアプレットにバンドルする必要があります。
共有Java EEライブラリを使用すると、1種類以上のJava EEモジュールを複数のエンタープライズ・アプリケーション間で簡単に共有できます。共有ライブラリは、JARファイルとしてアプリケーション・サーバーにデプロイできます。
詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverアプリケーションの開発』の第9章「共有Java EEライブラリおよびオプション・パッケージの作成」を参照してください。
共有ライブラリ・アーカイブを作成してデプロイするには:
デプロイメントを正常に行うには、デプロイメント・プロセスを処理する関係から、WebLogic Serverドメインのアプリケーション・サーバーが起動している必要があります。停止しているサーバーにデプロイすると、デプロイメント・ログ・ウィンドウのメッセージにはサーバーが停止していると表示されますが、再起動したときにアプリケーションがインストールされます。ログ・メッセージの内容は、次のようになります。
[02:27:21 PM] ---- Deployment started. ---- [02:27:21 PM] Target platform is (Weblogic 10.3). [02:27:23 PM] Retrieving existing application information [02:27:23 PM] Running dependency analysis... [02:27:23 PM] Building... [02:27:26 PM] Deploying 2 profiles... [02:27:26 PM] Wrote Web Application Module to /scratch/.../jdev/mywork/Application1/Project1/deploy/webapp1.war [02:27:26 PM] Wrote Enterprise Application Module to /scratch/.../jdev/mywork/Application1/application1.ear [02:27:26 PM] Deploying Application... [02:27:27 PM] [Deployer:149195]Operation 'deploy' on application 'application1' has been deferred since 'Server-2' is unavailable [02:27:27 PM] [Deployer:149034]An exception occurred for task [Deployer:149026]deploy application application1 on Server-2.: . [02:27:27 PM] Application Deployed Successfully. [02:27:27 PM] Elapsed time for deployment: 5 seconds [02:27:27 PM] ---- Deployment finished.
デプロイメントが正常に実行されたように見えても、サーバーを再起動したときデプロイメントが正常に終了しないという場合があります。たとえば、デプロイメント・プロセスの一環である検証の一部が実行されなかった、あるいは正常なデプロイメントに必要なライブラリが欠落しているなどの原因が考えられます。この場合、サーバーを再起動しても、再開されたデプロイメントが失敗します。
停止しているサーバーには、アプリケーションを1回しかデプロイできません。停止している同じサーバーに同じアプリケーションを再度デプロイしようとすると、エラーが表示されます。
アプリケーションをOracle WebLogic Serverにデプロイすると、複数のOracle WebLogic Server間で移行が可能になります。
最初のデプロイ時と同じ手順の一部を実行する必要がある場合があります。
一般に、アプリケーションを別のアプリケーション・サーバーに移行する際には、次の作業を行います。
ターゲットとなるアプリケーション・サーバーを正しいデータベース接続情報またはURL接続情報で構成します。
セキュリティ情報、たとえばJDBCデータソースをソースからターゲットに移行します。
新しいサーバーにアプリケーションをデプロイします。
アプリケーションは、デプロイが完了したら、Oracle WebLogic Serverからテストすることができます。
デプロイメントのログ・ウィンドウには、デプロイされたWebアプリケーションのコンテキスト・ルートURLが表示されます。ブラウザにアプリケーションのURLを入力して、デプロイ済のWebアプリケーションにアクセスできます。デプロイされたWebアプリケーションのURLが、たとえば次のようにデプロイメントのログ・ウィンドウに表示されます。
[03:08:20 PM] The following URL context root(s) were defined and can be used as a starting point to test your application: [03:08:20 PM] http://12.345.678.912:7101/Project1 [03:08:21 PM] Elapsed time for deployment: 7 seconds [03:08:21 PM] ---- Deployment finished. ----
URLをコピーしてブラウザに貼り付ければ、デプロイされたWebアプリケーションをテストできます。
ブラウザのプロキシ設定によっては、ホスト・マシンの完全なドメイン名を指定する必要があります。サーブレット・エンジンと、デプロイ済アプリケーションの表示に使用するブラウザが同じマシン上に存在する場合、ホスト名としてlocalhostを使用できます。
JDeveloperデプロイメントは、プロファイルと呼ばれる設計時データ構造の周辺に構築されます。一般的な実装は、JARアーカイブの構造を記述したArchiveProfileです。デプロイメント・プロファイルは、JDeveloperのプロジェクトまたはワークスペースの一部として作成できます。JDeveloperにはコマンド行ツールojdeployが用意されています。これを使用すると、JDeveloper GUIを起動せずに、ArchiveProfileのデプロイメントが可能になります。これは、最も単純な形式のデプロイメントです。これには次の機能があります。
ojdeploy
は、インプロセスでローカルにデプロイメントを実行することも、バックグラウンド・サーバーであるojserverに発行することもできます。詳細は、「ojserverの使用」を参照してください。
コマンド行からデプロイする前に、JDeveloperを少なくとも1回実行して、アプリケーションまたはプロジェクトのデプロイメント・プロファイルを作成する必要があります。
デプロイメント・プロファイルは、アプリケーションまたはプロジェクトのプロパティの一部として格納されます。
ojdeploy
は、jdeveloper_install
/jdeveloper/jdev/bin
のコマンド行から入手できます。次のように使用します。
ojdeploy <commandId>
詳細を確認するには、次のように入力します。
ojdeploy <commandId> -help
現在使用できるコマンドは、deployToArchive
(デフォルト)のみです。このコマンドにより、アーカイブ・ファイルにデプロイされます。
使用方法:
ojdeploy -profile <name> -workspace <jws> [ -project <name> ] [ <options> ] ojdeploy -buildfile <ojbuild.xml> [ <options> ] ojdeploy -buildfileschema
ojdeployで次の引数を使用できます。
表22-2 ojdeployで使用できる引数
引数 | 説明 |
---|---|
-buildfile |
バッチ・デプロイ用のビルドファイルへのフルパス。 |
-buildfileschema |
ビルドファイルの出力XMLスキーマ。 |
-profile |
デプロイするプロファイルの名前。 デプロイメント・プロファイルは、大きく2つのカテゴリに分類できます。1つは、アプリケーション(ワークスペース)・レベルで定義されるデプロイメント・プロファイルであり、もう1つは、プロジェクト・レベルで定義されるデプロイメント・プロファイルです。アプリケーション・プロファイルをデプロイする場合、ojdeployはアプリケーションの場所とプロファイルの名前を引数として取ります。プロジェクト・プロファイルをデプロイする場合、さらに |
-project |
プロファイルを検索できる |
-workspace |
JDeveloperのワークスペース・ファイル( |
ojdeployで次のオプションを使用できます。
表22-3 ojdeployで使用できるオプション
オプション | 説明 |
---|---|
-address |
デフォルト( |
-basedir |
ワークスペースのパス名を相対的に解釈できます。組込みマクロ |
-clean |
コンパイル前の出力ディレクトリのクリーン |
-datasources |
JEEアプリケーションの場合は非推奨。 |
-define |
カンマ区切りの名前=値のペアとして変数を定義します。 |
-failonwarning |
ビルド・システムが起動しないようにします。これは、単にワークスペースまたはプロジェクトをパッケージ化し、その時点でコンパイルしない場合に便利です。 |
-forcerewrite |
ojdeployを実行して内容が変更されなかった場合でも、出力ファイルが再書込みされます。 |
-nocompile |
ビルド・システムが起動しないようにします。これは、単にワークスペースまたはプロジェクトをパッケージ化し、その時点でコンパイルしない場合に便利です。 |
-nodatasources |
IDEのデータ・ソースを含めないでください。 |
-nodependents |
プロジェクトおよびプロファイルの依存性に移動しないように |
-ojserver |
ojserver上でデプロイメント・ジョブを実行します。他のオプションによって参照されるパスはすべて、サーバー上でアクセスできる必要があります。 |
-outputfile |
プロファイルから作成されるJARファイルをリダイレクトします。デフォルトは、プロジェクトまたはワークスペース内の ファイル拡張子の自動化: |
-project |
指定した場合、プロジェクトでプロファイルを検索するように |
-statuslogfile |
処理済のすべてのプロファイルとそれぞれのステータスのリストが格納されたXMLファイルを作成します。最後のサマリー・セクションをチェックすると、スクリプト全体の終了ステータスを簡単に確認できます。 |
-stderr |
各プロファイルおよびプロジェクトのファイルにこれらの各ストリームをリダイレクトできます。ファイルの名前またはパスでマクロを使用できます。 |
-stdout |
ファイルに標準出力をリダイレクトします。 |
-timeout |
1つのプロファイルのデプロイメントが中止されるまでの経過秒数を指定できます。そのプロファイルが他のプロファイル(同様にデプロイが必要)に依存する場合、この時間内にすべて完了する必要があります。 |
-updatewebxmlejbrefs |
web.xmlでEJB参照を更新します。 |
-workspace |
デプロイメント・プロファイルは、大きく2つのカテゴリに分類できます。1つは、アプリケーション(ワークスペース)・レベルで定義されるデプロイメント・プロファイルであり、もう1つは、プロジェクト・レベルで定義されるデプロイメント・プロファイルです。ワークスペース・プロファイルをデプロイする場合、 |
ojdeployで次の組込みマクロを使用できます。
表22-4 ojdeployで使用できる組込みマクロ
マクロ | 説明 |
---|---|
${workspace.name} |
|
${workspace.dir} |
|
${project.name} |
|
${project.dir} |
|
${profile.name} |
プロファイルの定義済の名前 |
${deploy.dir} |
デフォルトのデプロイ・ディレクトリ。通常、プロジェクト・レベルのプロファイルの場合は |
${base.dir} |
|
注意:
${project.name}と${project.dir}を使用できるのは、プロジェクト・レベルのプロファイルをデプロイする場合のみです。
例:
プロジェクト・レベルのプロファイルをデプロイする場合
ojdeploy -profile webapp1 -workspace /usr/jdoe/Application1/Application1.jws -project Project1 ojdeploy -profile webapp1 -workspace Application1/Application1.jws -basedir /usr/jdoe -project Project1
ワークスペース・レベルのプロファイルをデプロイする場合
ojdeploy -profile earprofile1 -workspace /usr/jdoe/Application1/Application1.jws
ワークスペースの全プロジェクトから全プロファイルをデプロイする場合
ojdeploy -workspace /usr/jdoe/Application1/Application1.jws -project \* -profile \*
ojbuild
ファイルからバッチ・モードでビルドする場合:
ojdeploy -buildfile /usr/jdoe/ojbuild.xml
ojbuild
ファイルを使用してビルドし、デフォルトの変数をビルド・ファイルに渡したり上書きする場合:
ojdeploy -buildfile /usr/jdoe/ojbuild.xml -define myhome=/usr/jdoe,mytmp=/tmp ojdeploy -buildfile /usr/jdoe/ojbuild.xml -basedir /usr/jdoe
ojbuild
ファイルを使用してビルドし、defaultセクションにパラメータを設定したり上書きする場合:
ojdeploy -buildfile /usr/jdoe/ojbuild.xml -nocompile ojdeploy -buildfile /usr/jdoe/ojbuild.xml -outputfile '${workspace.dir}/${profile.name}.jar' ojdeploy -buildfile /usr/jdoe/ojbuild.xml -define mydir=/tmp -outputfile '${mydir}/${workspace.name}-${profile.name}'
その他の例:
ojdeploy -workspace Application1/Application1.jws,Application2/Application2.jws -basedir /home/jdoe -profile app* ojdeploy -buildfile /usr/jdoe/ojbuild.xml -define outdir=/tmp,rel=11.1.1 -outputfile'${outdir}/built/${workspace.name}/${rel}/${profile.name}.jar' ojdeploy -workspace Application1/Application1.jws -basedir /home/jdoe -nocompile -outputfile '${base.dir}/${workspace.name}-${profile.name}' ojdeploy -workspace /usr/jdoe/Application1.jws -project * -profile * -stdout /home/jdoe/stdout/${project.name}.log ojdeploy -buildfile /usr/jdoe/ojbuild.xml -ojserver
Mac OS Xプラットフォームでojdeployを使用している場合は、jdev_install
/jdeveloper/jdev/bin/jdev.conf
ファイル内の変数SetSkipJ2SDKCheck
をtrueに設定する必要があります。エントリは次のようになります。
SetSkipJ2SDKCheck true
現在JDeveloperでは、Antスクリプトによるデプロイをサポートしています。詳細は、「Antを使用したコマンドラインからのデプロイ方法」を参照してください。
ojdeployを使用したコマンドラインによるデプロイは、バッチ・ファイルや他のスクリプトを使用して既存のプロジェクトやアプリケーションをデプロイする場合に特に便利です。
ビルド・スクリプトで定義したマクロ値を渡したりオーバーライドするには、-define
オプションを使用して、新しい値を指定します。
ojdeploy -buildfile /home/jdoe/ojbuild.xml -define "mycustomdir=/tmp"
これにより、mycustomdir
変数がビルド・スクリプトの<defaults>
セクションに追加されます。この変数が/tmp
値にすでに定義されている場合は置き換えられます。
ビルド・スクリプトに定義したパラメータ値を渡したりオーバーライドするには、適切なパラメータ・オプションを使用します。次に例を示します。
ojdeploy -buildfile /home/jdoe/ojbuild.xml -nocompile -nodatasources
これにより、-nocompile
と-nodatasources
パラメータがビルドファイルのdefaultセクションに追加されます。
コマンドライン・デプロイメントでは、1回の起動で複数のアプリケーションをデプロイできます。複雑な制御が必要な場合は、ojdeployでXMLビルド・スクリプトを指定して処理し、検出されたすべてのデプロイ・タスクを実行できます。マクロおよびワイルドカードは、コマンドラインとバッチ・モードの両方で使用できます。マクロは、まとめて連結したり、ネストすることができます。
デプロイ対象の各プロファイルは、アプリケーションとプロジェクトによって修飾されます。また、各プロファイルの出力は、異なる出力ファイルや場所に出力できます。さらに、コール側スクリプトではアプリケーション内のプロジェクトを認識しないため、基準に一致する全部または一部のプロジェクトのみがデプロイされます。このような入力や基準を指定するコマンドライン構文は煩雑となり、柔軟性が失われる場合があります。
ビルド・ファイルはojdeploy
に渡すことができます。ビルドファイルには、複数の<deploy>
タスクとともに、環境を設定できる共有の<defaults>
セクションが含まれます。各デプロイ・タスクでは、デプロイのタイプ(前述のセット)を指定し、必要に応じてデフォルト値をカスタマイズします。各タスクでは、そのタスクのスコープに適用するパラメータ引数内で適用可能なワイルドカードも使用できます。プリプロセッサはビルドファイルを解析してojdeployに渡し、必要に応じてワイルドカードを展開して変数を置換します。
ビルドファイルの利用には、コマンドライン構文にくらべて次の利点があります。
より多くのパラメータをojdeploy
に追加できます。パラメータのインプリメンタに、バッチ・ビルドの概念についての認識は不要です。
煩雑な場合でも、コマンドライン構文を単純にできます。
現在のコンテキストに基づいてパラメータを動的に評価し、プリプロセッサ・マクロの事前定義リストにアクセスできます。たとえば、OutputFileの場所をc:\temp\${
profile.name
}
として指定できます。この場合、マクロ${
profile.name
}
が自動的に追加されます。
サンプルのビルドファイルを次に示します。すべてのデプロイ処理を起動するためのコマンドラインはojdeploy ojdeploy-build.xml
です。ファイルは上から下へ処理されます。
<?xml version="1.0" encoding="US-ASCII" ?> <ojdeploy-build basedir="/usr/jdoe/"> <!-- Defines default parameters for all deploy tasks. Also defines some variables strictly for use within this file in macros --> <defaults> <parameter name="profile" value="*"/> <parameter name="nocompile" /> <-- define a macro --> <variable name="customdir" value="/var/projects/fin/"/> </defaults> <!-- Select all .jws files in location ${customdir} called absoluteFile1.jws, absoluteFile2.jws. Open all projects. Deploy profiles p1, p2, p3 in each project, in each workspace. --> <deploy> <parameter name="workspace" value="${customdir}/absoluteFile1.jws,${customdir}/absoluteFile2.jws"/> <parameter name="project" value="*"/> <-- Override default profile parameter --> <parameter name="profile" value="p1,p2,p3"/> </deploy> <!-- Open relativeFile1.jws in the base directory Open all projects. Deploy all profiles (default for "profile" parameter is "*") --> <deploy> <parameter name="workspace" value="relativeFile1.jws"/> <parameter name="project" value="*"/> </deploy> <!-- Open relativeFile2.jws in base directory. Open all Projects Deploy profiles matching the patter "web*" --> <deploy> <parameter name="workspace" value="relativeFile2.jws"/> <parameter name="project" value="*"/> <parameter name="profile" value="web*"/> </deploy> </ojdeploy-build>
プロジェクト名とプロファイル名は、"*"、"name*"、"name1,name2,name3,..."、またはこれらの組合せとして指定できます。アプリケーション名は列挙の必要があるため、アプリケーション名に"*"は使用できませんが、"application1"または"application1,application2,application3"のように指定できます。
次に例を示します。
adf* (プロファイル)
View* (プロジェクト)
*Controller(すべてのコントローラ・プロジェクト)
アプリケーションでワイルドカードを使用する例:
<ojdeploy-build basedir= "/home/jdoe" > <deploy> <parameter name= "workspace" value= "Application1.jws,Application2.jws" /> <!-- above pattern gets /home/jdoe/Application1.jws and /home/jdoe/Application2.jws --> . . . </deploy> /ojdeploy-build>
-statuslogfile
パラメータでは、ユーザーは、デプロイメント・バッチ全体のビルド・サマリーを作成できます。マクロを使用せず、絶対パスを指定してください。
ログ・ファイルには、処理されたデプロイ・タスクと各タスクのステータスがXML形式でリストされます。ステータスはSUCCESS
またはFAILED
のいずれかで、exitcode属性が含まれます。exitcodeに指定できる値は、次のとおりです。
0 - 成功
1 - 致命的エラー(NPE、OutOfMemoryなど)
2 - JDeveloper構成エラー(拡張子の欠落など)
4 - デプロイ・エラー(コンパイル、デプロイ例外など)。すべての終了コードはビットごとにOR演算されます。
各ログの最後にあるサマリー・セクションでは、組み合されたステータスを使用できます。
次に、バッチ・デプロイメント・ログ出力の例を示します。
<?xml version="1.0"?> <ojdeploy-log> <deploy-task> <target> <profile>webapp1</profile> <workspace>/scratch/jdoe/jdev/mywork/Application3/Application3.jws</workspace> <project>Project1.jpr</project> </target> <exception msg="**** One or more compilation errors prevented deployment from continuing."> oracle.jdeveloper.deploy.DeployException: **** One or more compilation errors prevented deployment from continuing. at oracle.jdevimpl.deploy.common.ModulePackagerImpl.compileDependents(ModulePackagerImpl.java:143) at oracle.jdeveloper.deploy.common.ModulePackager.compile(ModulePackager.java:65) at oracle.jdeveloper.deploy.common.ModulePackager.prepareImpl(ModulePackager.java:52) at oracle.jdeveloper.deploy.common.AbstractDeployer.prepare(AbstractDeployer.java:69) at oracle.jdevimpl.deploy.fwk.WrappedDeployer.prepareImpl(WrappedDeployer.java:32) at oracle.jdeveloper.deploy.common.AbstractDeployer.prepare(AbstractDeployer.java:69) at oracle.jdevimpl.deploy.fwk.WrappedDeployer.prepareImpl(WrappedDeployer.java:32) at oracle.jdeveloper.deploy.common.AbstractDeployer.prepare(AbstractDeployer.java:69) at oracle.jdevimpl.deploy.fwk.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:411) at oracle.jdevimpl.deploy.fwk.DeploymentManagerImpl$1.run(DeploymentManagerImpl.java:281) </exception> <status exitcode="4">FAILED</status> </deploy-task> <deploy-task> <target> <profile>archive1</profile> <workspace>/scratch/jdoe/jdev/mywork/Application3/Application3.jws</workspace> <project>Project1.jpr</project> </target> <exception msg="**** One or more compilation errors prevented deployment from continuing."> oracle.jdeveloper.deploy.DeployException: **** One or more compilation errors prevented deployment from continuing. at oracle.jdevimpl.deploy.common.ModulePackagerImpl.compileDependents(ModulePackagerImpl.java:143) at oracle.jdeveloper.deploy.common.ModulePackager.compile(ModulePackager.java:65) at oracle.jdeveloper.deploy.common.ModulePackager.prepareImpl(ModulePackager.java:52) at oracle.jdeveloper.deploy.common.AbstractDeployer.prepare(AbstractDeployer.java:69) at oracle.jdevimpl.deploy.fwk.WrappedDeployer.prepareImpl(WrappedDeployer.java:32) at oracle.jdeveloper.deploy.common.AbstractDeployer.prepare(AbstractDeployer.java:69) at oracle.jdevimpl.deploy.fwk.WrappedDeployer.prepareImpl(WrappedDeployer.java:32) at oracle.jdeveloper.deploy.common.AbstractDeployer.prepare(AbstractDeployer.java:69) at oracle.jdevimpl.deploy.fwk.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:411) at oracle.jdevimpl.deploy.fwk.DeploymentManagerImpl$1.run(DeploymentManagerImpl.java:281) </exception> <status exitcode="4">FAILED</status> </deploy-task> <deploy-task> <target> <profile>ejb1</profile> <workspace>/scratch/jdoe/jdev/mywork/Application3/Application3.jws</workspace> <project>Project3.jpr</project> </target> <status exitcode="0">SUCCESS</status> </deploy-task> <summary> <start-time>2007-12-19 12:10:42 PST</start-time> <end-time>2007-12-19 12:10:45 PST</end-time> <total-tasks>3</total-tasks> <failures>2</failures> <status exitcode="4">FAILED</status> </summary> </ojdeploy-log>
JDeveloperでのデプロイは、デプロイメント・プロファイルを基にして構築されています。一般的な実装は、JARアーカイブの構造を記述したArchiveProfileです。
デプロイメント・プロファイルは、プロジェクトまたはアプリケーションの一部として作成できます。ojdeploy
を使用すると、JDeveloper IDEを起動せずに、ArchiveProfileのデプロイが可能になります。
コマンド行デプロイメントには、JDeveloperのインストールが必要ですが、このインストールはヘッドレス・モードで起動されるため、JDeveloper IDEは表示されず、ヘッドレス・モードに定義されているすべての拡張機能がロードされます。この形式のデプロイでは、JDeveloperのアプリケーションとプロジェクト、およびそのメタデータを読み込むことができます。
コマンド行デプロイメントを起動するAntスクリプトは、手動で作成する必要があります。結果としてデプロイされるアーカイブは、使用しているJDeveloperのバージョン、およびコマンド行デプロイメントの起動時に有効な拡張機能によって異なります。
注意:
JDeveloperから、アプリケーション用の.ear
ファイルを生成することをお薦めします。.ear
ファイルは、デプロイに必要な適切なクラス依存性をすべて備えて生成されます。.ear
ファイルを生成せずに直接アプリケーションを参照してAntでデプロイするには、クラスとJARファイルの依存性を手動で解決する必要がある場合があります。
ojdeploy
タスクはAnt <exec>
タスクの拡張であるため、そのタスクの有効な属性はojdeploy
で使用できます(arg
、failonerror
など)。
たとえば、エラーが発生した場合にデプロイメントを停止するには、failonerror="true"
を追加します。
詳細は、『Apache Ant Manual』(http://ant.apache.org/manual)のタスクの実行に関する項を参照してください。
build.propertiesファイルはbuild.xmlとともに生成され、コマンド行デプロイメントに必要な追加の変数を定義します。
build.xmlの例を次に示します。
#Fri Feb 15 10:45:22 PST 2008 #Sun Feb 24 18:47:36 PST 2008 javac.nowarn=off javac.debug=on build.compiler=oracle.ojc.ant.taskdefs.OjcAdapter output.dir=classes oracle.home=../../oracle/ javac.deprecation=off oracle.jdeveloper.ant.library=/scratch/jdoe/oracle/jdev//lib/ant-jdeveloper.jar oracle.jdeveloper.deploy.dir=/scratch/jdoe/Application7/Project1/deploy/ oracle.jdeveloper.ojdeploy.path=/scratch/jdoe/oracle/jdev//bin/ojdeploy oracle.jdeveloper.workspace.path=/scratch/jdoe/Application7/Application7.jws oracle.jdeveloper.project.name=Project1 oracle.jdeveloper.deploy.profile.name=* oracle.jdeveloper.deploy.outputfile=/scratch/jdoe/Application
Antビルド・スクリプトは、JDeveloperの外部で実行できます。実行するには、build.xmlが格納されたディレクトリに変更してAntを実行します。JDeveloper内からも実行できます。実行するには、「アプリケーション」ウィンドウでbuild.xmlノードを右クリックし、「すべて」または「デプロイ」ターゲットを選択します。
注意:
デフォルトでは、コマンドライン・デプロイメント・タスクには、タスクとして有効なnocompileオプションがあり、コンパイル・タスクに依存しています。この依存性が削除されている場合は、nocompileオプションも削除できます。
JDeveloperから、アプリケーション用の.earファイルを生成することをお薦めします。.earファイルは、デプロイに必要な適切なクラス依存性をすべて備えて生成されます。.earファイルを生成せずに直接アプリケーションを参照し、Antを使用してデプロイするには、クラスとJARファイルの依存性を手動で解決する必要がある場合があります。
build.propertiesファイルの例を次に示します。
Buildfile: /scratch/jdoe/Application7/Project1/build1.xml init: compile: deploy: [ora:ojdeploy] [ora:ojdeploy] Oracle JDeveloper Deploy 11.1.1.0.0 [ora:ojdeploy] Copyright (c) 2008, Oracle. All rights reserved. [ora:ojdeploy] [ora:ojdeploy] ----build file---- [ora:ojdeploy] <?xml version = '1.0' standalone = 'yes'?> [ora:ojdeploy] <ojdeploy-build> [ora:ojdeploy] <deploy> [ora:ojdeploy] <parameter name="workspace" value="/scratch/jdoe/Application7/Application7.jws"/> [ora:ojdeploy] <parameter name="project" value="Project1"/> [ora:ojdeploy] <parameter name="profile" value="*"/> [ora:ojdeploy] <parameter name="nocompile" value="true"/> [ora:ojdeploy] <parameter name="outputfile" value="/scratch/jdoe/Application7/Project1/deploy/${profile.name}"/> [ora:ojdeploy] </deploy> [ora:ojdeploy] <defaults> [ora:ojdeploy] <parameter name="buildfile" value="/scratch/jdoe/Application7/Project1/deploy/ojdeploy-build.xml"/> [ora:ojdeploy] <parameter name="statuslogfile" value="/scratch/jdoe/Application7/Project1/deploy/ojdeploy-statuslog.xml"/> [ora:ojdeploy] </defaults> [ora:ojdeploy] </ojdeploy-build> [ora:ojdeploy] ------------------ [ora:ojdeploy] ---- Deployment started. ---- Feb 24, 2008 6:49:51 PM [ora:ojdeploy] Target platform is (WebLogic 10.3). [ora:ojdeploy] Running dependency analysis... [ora:ojdeploy] Wrote JAR file to /scratch/jdoe/Application7/Project1/deploy/archive1.jar [ora:ojdeploy] Elapsed time for deployment: less than one second [ora:ojdeploy] ---- Deployment finished. ---- Feb 24, 2008 6:49:51 PM [ora:ojdeploy] ---- Deployment started. ---- Feb 24, 2008 6:49:51 PM [ora:ojdeploy] Target platform is (Java Enterprise Edition 1.5). [ora:ojdeploy] Running dependency analysis... [ora:ojdeploy] Wrote WAR file to /scratch/jdoe/Application7/Project1/deploy/WindowMobile.war [ora:ojdeploy] Elapsed time for deployment: less than one second [ora:ojdeploy] ---- Deployment finished. ---- Feb 24, 2008 6:49:52 PM [ora:ojdeploy] Status summary written to /scratch/jdoe/Application7/Project1/deploy/ojdeploy-statuslog.xml BUILD SUCCESSFUL Total time: 19 seconds
ojdeploy
コマンドには、拡張をojdeployプロセスに組み込むことができるフレームワークがあります。新しいフレームワークが登場する前は、ojdeploy
では、アーカイブへのデプロイメントのみが可能でした。新しいフレームワークは、DeployCommand実装の作成と実行に対応するように設計されています。このフレームワークでは、たとえば、DeployCommandに対するojdeploy
のサポートを定義する拡張が可能です。
新しいフレームワークでは、次のような拡張が可能です。
各自のOJDeploy引数および解析ルールを定義します。
各自のコマンド・パーサーおよびモデルを定義します(オプション)。
ContextIteratorsを介した各自の引数の拡張およびワイルドカード・ロジックを定義します(オプション)。
DeployCommandコンテキストの正確な構成を制御します。
DeployCommandインスタンスの作成と設定を制御します。
このフレームワークは、柔軟性が大幅に向上する一方で、使用しやすいメカニズムが拡張作成者に提供されるように設計されています。これは、フレームワークに様々な組込みコンポーネント(AbstractCommandSupportやAbstractContextIteratorなど)が用意されているためです。
表22-5 クラスの種類
クラス名 | 説明 |
---|---|
Arguments |
ojdeployプロセスに渡されるコマンド行引数を表します。Buildfilesパラメータ/変数も引数に変換されて処理されることに注意してください。 |
BuildScript |
BuildScriptは、OJDeployプロセスの入力であるビルドファイルを表します。BuildScriptは、ビルドファイルから作成することも、コマンド行引数を解析することで作成することもできます。ただし、BuildScriptは、必ずOJDeployプロセス中に作成されます。 |
OJBuildScriptSupport |
このクラスは、BuildScriptをojdeploycommanditeratorに変換します。次のシーケンス図に示すように、このクラスは、OJCommandSupportの作成、引数の解析およびOJContextIteratorsの作成を制御します。 |
OJCommandSupport |
このクラスは、指定のDeployCommandの適切な作成をサポートする場合に使用されます。たとえば、DeployToArchiveCommandSupportが、アーカイブ・ファイルへのプロファイルのデプロイメントを可能にする1つの実装であるとします。この場合、各自の |
Context |
IDEコンテキスト。コンテキストは重大です。これは、DeployCommandFactoryを介してDeployCommandインスタンスを作成する目的で使用されるためです。ojdeployの拡張として、DeployCommandインスタンスのインスタンス化に必要なコンテキストを構築する必要があります。 |
OJContextIterator |
コンテキストのイテレータ。各種コンテキスト・イテレータが、使用できるように事前に作成されていることに注意してください。たとえば、ojdeployフレームワークには、指定のワークスペース(WorkspaceContextIterator)、プロジェクト(ProjectContextIterator)およびプロファイル(ProfileContextIterator)に基づきコンテキスト・インスタンスを移入するイテレータがあります。おそらく各自のContextIteratorを作成する必要はありませんが、作成する場合は、その目的で拡張できるAbstractContextIteratorもフレームワークに含まれます(この詳細は、各自のOJContextIteratorの作成方法に関する次の項で説明します。) |
DeployCommand |
ojdeployプロセスの全体の目的は、DeployCommandインスタンスを作成して実行することです。DeployCommandはIDEコマンドの拡張です。 |
DeployService |
DeployServiceは、ojdeployプロセスでのDeployCommandの作成と実行をojdeployプロセスが制御する場合に呼び出されます。これは、次のシーケンス図に示すように、実際はOJDeployフレームワークAPIのクライアントです。 |
OJCommandModel |
OJCommandModelは、IDE CommandModelの拡張です。これは、OJCommandParserに解析される引数を保持します。 |
OJCommandParser |
OJCommandParserは、引数の解析とOJCommandModelの作成に使用されます。 |
OJCommand |
DeployCommandと混同しないでください。OJCommandは、単純にCommandID (「Deployment.DeployToFileなど」)やコマンド・ラベル(DeployToArchive)を保持する簡易クラスです。CommandIDは、DeployCommandFactoryがDeployCommandを作成する場合に使用されます。コマンド・ラベルは、コマンド行またはビルドファイルでDeployCommand識別子として使用されるものです。コマンド・ラベルは、CommandIDに対応するユーザー・フレンドリな表現です。そのため、2つの間には1対1の関係があります。 |
OJDeployCommandIterator |
OJDeployCommandIteratorは、指定のBuildScriptのすべてのDeployCommandインスタンスを反復する場合に使用されます。OJDeployCommandIteratorをOJContextIteratorsとともに使用すると、すべてのDeployCommandコンテキスト・オブジェクト(ワークスペース、プロジェクト、プロファイルなど)の遅延ロードが可能になり、さらに、ojdeployプロセス中に適切なリソース管理を行う目的で各コマンドの実行後にそれらのオブジェクトが自動的にリリースされます。 |
図22-4 シーケンス図
現在の制限事項
GUIモードでIDE内からデプロイされたようにデプロイ済モジュールをojdeployで再作成するには、完全に同じJDeveloperインストールを使用する必要があります。Jdeveloperインストールに変更がある場合、ロードされる拡張あるいはそのバージョンも変更されている可能性があるため、最終結果も変わることがあります。
ojdeploy
の起動時間は、ヘッドレスJDeveloperの起動時間によって異なります。このモードに登録されるすべての拡張を初期化する必要があります。この時間は、ヘッドレス・モードの場合、各拡張がそれ自体を最適化することで短縮できます。大規模なビルドの場合、-ojserver
オプションは、バックグラウンドで実行するサーバーにデプロイ・ジョブを発行できます。OJServerを参照
ヘッドレス属性の使用
ojdeploy
は、ヘッドレス(非GUI)モードでJDeveloperを実行します。これにより、このモードをサポートする各種拡張がすべて有効になります。
ヘッドレス・モードでの実行時にIDEアドイン(oracle.ide.Addin
)がロードされていることを確認するには、これらをheadless=true
タグでマーク付けする必要があります。このようにマーク付けされていないアドインは、これらのヘッドレス・アドインから参照されません。
Addin.initialize(
)中は、現在アクティブなワークスペースやプロジェクトなどのすべてのIDEコンテキストが利用可能です。
ojdeployで実行する必要がある拡張から提供されるすべてのデプロイメント・ツールキットもheadless=true
属性でマーク付けする必要があります。
ojserver
は、サーバー・モードで動作し、リモート・クライアントのリクエストをリスニングする、JDeveloperのヘッドレス・バージョンです。クライアントであり、RMIを使用してサービス・リクエストをサーバーに送信します。ojserverの主な目的は、JDeveloperをヘッドレス・モードで実行するバッチ・スクリプトでコマンドライン・ツールを使用する際に発生する起動時間を短縮することです。ojserverはoracle/jdeveloper/jdev/bin
ディレクトリにあります。
ojserverの使用方法、パラメータ、オプションおよび例を表示するには、jdeveloper_install
/jdeveloper/jdev/bin
のコマンドラインでojserver
と入力します。
ojdeploy
は、インプロセスでローカルにデプロイメントを実行することも、-ojserver
オプションを使用して、バックグラウンドのOJServerに発行することもできます。-ojserver
を使用する場合、ojdeploy
は、デプロイメントが完了するまでブロックし、終了コードは、サーバーでのデプロイメントの発生状況に応じて設定されます。
ojserver
での実行時にローカル・デプロイメントのすべてのオプションも利用できますが、絶対パスを使用する場合、サーバーでそのパスにアクセスできる必要があります。
Java Web Startは、Java SE 6以上の一部としてJava Runtime Environment (JRE)に含まれます(http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136112.html)。
JDeveloperでは、Java Web Startテクノロジの基盤になる、XMLベースのJNLP (Java Network Launching Protocol)定義の作成がサポートされています。Java Web Startを使用すると、Javaアプリケーションをデプロイしてインターネット・ブラウザから起動できます。Java Web Startでは、Javaクライアント・アプリケーションおよびアプレットをWebサーバー上で管理し、ユーザーがそれをクライアント・マシンにダウンロードして実行できます。JDeveloperのJava Web Start対応の作成ウィザードを使用すると、Webサーバーで管理されるが、クライアント・マシンでダウンロードおよび実行されるアプリケーションおよびアプレットを設定できます。
注意:
次回のレビューでこの注意点について再度確認します
2013年4月のJava SE 7 Update 21以降、すべてのJavaアプレットおよびWeb Startアプリケーションは、信頼できる証明書で署名することを求められます。7u25以降、署名する前に、すべてのファイルをJARに追加する必要があります。詳細は、Java Webサイト(http://www.oracle.com/technetwork/java/javase/tech/java-code-signing-1915323.html)を参照してください。
Java Web Startアプリケーションを開発するプロセスは、次のように要約できます。
Javaアプリケーションを開発します。
JDeveloper IDE内のJava Web Startで、アプリケーションを実行するユーザーの体験をシミュレートします。
JDeveloperのJava EE Webデプロイ・プロセスを使用して、本番アプリケーションをWebサーバーに移動します。
注意:
JDeveloperのJava Web Startを使用してアプリケーションおよびアプレットを起動するには、Java Web Startソフトウェアをダウンロードしてインストールする必要があります。アプリケーションやアプレットのユーザーも、それぞれのマシンにソフトウェアをインストールする必要があります。
Java Web Startと、Java Web Startソフトウェアのダウンロードの詳細は、http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136112.htmlを参照してください。
Java Web Startとアプレットは同様のテクノロジに見えますが、いくつかの相違点があります。
アプレットのアプローチがWebを中心にしたJavaアプリケーションのデプロイであるのに対し、Java Web StartではWebブラウザに依存せずにアプリケーションのJARファイルのダウンロードが行われます。Java Web StartではWebブラウザを介してJava Web Start JNLPディスクリプタがダウンロードされた後で、アプリケーション・リソースがダウンロードされます。JNLPディスクリプタによってJava Web Startが実際のダウンロードを起動し、実行します。
アプリケーションのユーザーが体験するアプレットの動作は、Java Web Startと同じですが、Java Web Startではアプレットの場合のようにWebブラウザに関連付けられていません。アプリケーションが実行されたらWebブラウザは閉じることができ、アプリケーションはそのままJava Web Startで実行されます。
Java Web Startソフトウェアをクライアント・マシンにインストールした後、アプリケーション・ユーザーはWebページのリンクをクリックして、アプリケーションとアプレットを実行できます。アプリケーションがコンピュータにない場合、Java Web Startはアプリケーション・ライブラリのあるWebサーバーから必要なすべてのファイルを自動的にダウンロードします。そして、デスクトップ上のアイコンやブラウザ・リンクからいつでもアプリケーションを再起動できるように、ファイルをクライアント・コンピュータにキャッシュします。Java Web Startは必要に応じて更新を行うので、常に最新バージョンのアプリケーションがユーザーに提示されます。
アプリケーションをWebサーバー上で管理する一方で、アプリケーション・ユーザーはJava Web Startを使用してクライアント・マシン上でアプリケーションおよびアプレットを実行できます。Java Web StartとWebサーバーによるダウンロードをサポートするために、Java Web Start対応の作成ウィザードでは次のファイルが生成されます。
Java Web Startでアプリケーションをダウンロードして起動するために必要なJava Network Launching Protocol (JNLP)定義。.jnlp
ファイルには、アーカイブ・ファイルの記述と、このインスタンスにアプレットまたはアプリケーションが含まれているかどうかの記述があります。
Webサーバーからクライアントへのダウンロードを開始するためのURLを含んだHTMLファイル。HTMLファイルの作成はオプションですが、ファイルを手動で作成する場合を除いて、作成することを強くお薦めします。
アプリケーションをWebサーバー上で管理する一方で、ユーザーはJava Web Startを使用してクライアント・マシン上でアプリケーションおよびアプレットを実行できます。Java Web StartとWebサーバーによるダウンロードをサポートするために、Java Web Start対応の作成ウィザードでは次のファイルが生成されます。
JDeveloperでは統合WebLogic Server Webサーバーが提供されます。これを使用すると、Java Web Startで使用するWebアプリケーション・アーカイブのデプロイおよびダウンロードのプロセスをシミュレーションできます。JDeveloperでは、J2SEのデプロイメント・プロファイルの規則に従って、クライアント・マシンで実行されるコンポーネントのアーカイブ(シンプル・アーカイブ)とWebサーバーにデプロイされるコンポーネントのアーカイブ(Webアプリケーション・アーカイブ)が行われます。
Java Web Startの設定方法
クライアント・マシンにダウンロードされ、実行されるアプリケーションのソース・ファイルを含んだシンプルJavaアーカイブ.jar
ファイルを作成します。
JDeveloperで「Java Webサービスの作成」ウィザードを起動し、アプリケーションやアプレットをクライアント・マシンでダウンロードして実行できるようにするHTMLファイルおよびJNLPファイルを作成します。
WebサーバーにデプロイするWebアプリケーション・アーカイブ(.war
)ファイルを作成します。このファイルには、JDeveloper myworkフォルダにあるpublic_html
ディレクトリの内容が含まれ、JAR、HTMLおよびJNLPファイルが含まれます。
注意:
JDeveloperの組み込まれたWebサーバーを使用するためにアプリケーションをデプロイする必要はありません。JDeveloperにはデフォルトのweb.xml
定義があり、それによってJDeveloperのmywork
フォルダのpublic_html
の内容が指定されます。
Webサーバーを設定したら、生成された.html
ファイルを使用して、JDeveloperでJava Web Startソフトウェアを起動できます。Java Web StartではWebブラウザを使用して、.jnlp
ファイルで識別されたコンポーネントがダウンロードされます。.jnlp
ファイル内の別の定義では、コンポーネントをアプリケーションとして実行するのか、セキュアなアプレットで実行するのかが特定されます。Java Web Startを起動し、ダウンロードを完了したら、Webブラウザを閉じてアプリケーションやアプレットの実行を続けることができます。
Java Network Launching Protocol定義ファイルapplication-name.jnlp
は、Java Web Start対応の作成ウィザードを使用してJavaクライアントを作成し、Javaのアプリケーションやアプレットをダウンロードしてクライアント・マシンで実行するときに自動的に作成されます。ただし、application-name.jnlp
のコンテンツを制御する必要がある場合は、使用する独自のファイルを手動で作成できます。
注意:
この項目がグレー表示されている場合、application-name.jnlp
ファイルがプロジェクトですでに作成されていることを示します。プロジェクトごとに有効な各デプロイメント・ディスクリプタ・タイプは、1つのみです。
Java Web Start (.jnlp)ファイルを手動で作成するには、次の手順を実行します。
Java Web Startの詳細は、http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136112.htmlを参照してください。
Java Web Startでアプリケーションをダウンロードして実行する前に、JDeveloperのJava EE Webデプロイメント・プロセスを使用して、サーバーを設定できます。
アプリケーションをWebサーバーに常駐させると、メンテナンスが非常に容易になります。Java Web Startは、ユーザーがアプリケーションを実行するたびに、アプリケーションの更新の確認およびダウンロードを行います。
Webサーバーへのデプロイ用のJavaクライアント・アプリケーションを作成するには、次の手順を実行します。
作成したWARまたはEARをターゲット・アプリケーション・サーバーにデプロイする準備ができた後は、必ずアプリケーション・サーバー接続を作成してください。
注意:
Webモジュールは、ターゲット・デプロイメント・ディレクトリにデプロイされます。
Webアプリケーション・デプロイメント・ディスクリプタが、Webアプリケーション・アーカイブ(WAR)・ファイルWEB-INF/web.xml
内にあることを確認してください。
Java Web Start対応の作成ウィザードを使用して、Javaアプリケーションおよびアプレットをクライアント・マシンにダウンロードして実行するためにJava Web Startソフトウェアで使用されるXMLベースのJNLP (Java Network Launching Protocol)定義ファイルを作成します。
注意:
JDeveloperのJava Web Startを使用してアプリケーションおよびアプレットを起動するには、Java Web Startソフトウェアをダウンロードしてインストールする必要があります。アプリケーションやアプレットのユーザーも、それぞれのマシンにソフトウェアをインストールする必要があります。参照
http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136112.html
アプリケーションやアプレットは一連のJARファイルで配信する必要があり、イメージ、構成ファイルおよびネイティブ・ライブラリなどすべてのアプリケーション・リソースも、JARファイルに含める必要があります。リソースは、ClassLoader getResource
その他のメソッドを使用して検索する必要があります。Java Web Startでは、JARファイルのみがWebサーバーからクライアントに転送されます。詳細は、http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136112.html
を参照してください。
ウィザードでは、JNLPファイルと(オプションで)HTMLファイルがプロジェクトに追加されます。Java Web Startでは、これらの生成されたファイルを使用して、どのアプリケーション・ソースをWebサーバーにダウンロードするかが特定されます。
Java Web Startでアプリケーションをダウンロードして起動するには、Java Network Launching Protocol (JNLP)定義が必要です。.jnlp
ファイルには、アーカイブ・ファイルの記述と、このインスタンスにアプレットまたはアプリケーションが含まれているかどうかの記述があります。
HTMLファイル。HTMLファイルの作成はオプションですが、ファイルを手動で作成する場合を除いて、作成することを強くお薦めします。HTMLファイルには、Webサーバーからクライアントへのダウンロードを開始するためのURLが含まれます。
Java Web Start対応の作成ウィザードを起動してJNLPおよびHTMLファイルを作成する前に、シンプル・アーカイブ(JAR)ファイルを作成する必要があります。また、mainファンクションが存在するクラスを指定するよう要求されるため、そのクラスを確認する必要があります。
アプリケーションまたはアプレットのJNLP定義を作成するには、次の手順を実行します。
Java Web StartとともにJSPやサーブレットを使用することもできますが、手動でファイルを設定してコンテンツ・タイプを変更する必要があります。contentType = application/x-java-jnlp-file
を最初の行に指定したJNLPの例を次に示します。
<%@ page contentType="application/x-java-jnlp-file" %> <?xml version="1.0" encoding="utf-8"?> <jnlp spec="1.0+" codebase="http://192.168.1.102:8888" href="jnlpfile.jnlp"> <information> <title>Test</title> <vendor>Oracle</vendor> <homepage href="Test.html"/> <description>Encryption Tool</description> <icon href="images/frontpage.gif"/> <offline-allowed/> </information> <security><all-permissions/></security> <resources> <j2se version="1.3"/> <jar href="/apps/archive1.jar" main="true" download="eager" /> </resources> <application-desc main-class="oracle.Ide"> </application-desc> </jnlp>
Java Web Startでアプリケーションをダウンロードして実行する前に、JDeveloperの簡単なJava EE Webデプロイメント・プロセスを使用して、Webサーバーを設定できます。
アプリケーションをWebサーバーに常駐させると、メンテナンスが非常に容易になります。Java Web Startは、ユーザーがアプリケーションを実行するたびに、アプリケーションの更新の確認およびダウンロードを行います。
Javaクライアント・アプリケーションをWebサーバーにデプロイするには、次の手順を実行します。
注意:
Webアプリケーション・デプロイメント・ディスクリプタが、Webアプリケーション・アーカイブ(WAR)・ファイルWEB-INF/web.xml
内にあることを確認してください。
Oracle JDeveloper Weblogic SCA Spring拡張機能は、WebLogic SCAとオープン・ソースのSpringフレームワークのための統合サポートを提供します。
この拡張機能で、次のものを作成できます。
WebLogic SCA対応のプロジェクト。JARファイルとしてデプロイでき、それをデプロイのためのEARファイルに、またはWARファイルとして含めることができます。
Springフレームワーク・プロジェクト。
この拡張機能では、JDeveloperでWebLogic SCAアプリケーションを作成し、それをOracle WebLogic Serverにデプロイできます。WebLogic SCAは、OASIS Service Component Architecture Springコンポーネント実装仕様のサブセットに基づいています。詳細は、https://www.oasis-open.org
を参照してください。
サービス・コンポーネント・アーキテクチャ(SCA)はエンタープライズ・アプリケーションおよびシステムを統合および再利用可能なモジュラ・ビジネス・サービスとして構築するためのモデルを提供します。WebLogic SCAは、POJO (Plain Old Java Object)を使用したSCAアプリケーションの開発とデプロイをサポートしています。SCAでは、コンポーネントと通信が別個に実装されています。WebLogic SCAでは、POJOを使用してJavaアプリケーションを記述でき、使用可能な各種のプロトコルを介して、コンポーネントをSCAサービスとして公開し、参照を介してアクセスできます。これを行うにはSpringアプリケーション・コンテキストに構成されたSCAセマンティクスを使用します。SCAの観点では、WebLogic Spring SCAアプリケーションは、SCAサービスと参照を適切なバインディングで宣言するSpring SCAコンテキスト・ファイルとPOJOの集合です。WebLogic Spring SCAアプリケーションは、変更なしにOracle SOAコンポジットのコンポーネントとして使用できます。
WebLogic Spring SCAアプリケーションはWebLogic SCA Runtimeで実行されます。ランタイムが共有Webアプリケーション・ライブラリとしてWebLogic Serverにデプロイされるまで、アプリケーションをそこにデプロイできません。詳細は、「WebLogic SCAアプリケーションを統合WebLogic Serverにデプロイする方法」を参照してください。
Oracle WebLogic SCAの詳細は、『Oracle Fusion Middleware Oracle WebLogic Server WebLogic SCAアプリケーションの開発』を参照してください。
SpringはエンタープライズJavaアプリケーションの開発を簡単にするオープンソースのフレームワークです。Springフレームワークには、各層のモデルと、Javaアプリケーションの機能領域が含まれます。POJOの使用に重点が置かれ、制御の概念と依存性インジェクションの逆転を利用してアスペクト指向のプログラミングを実装します。
Weblogic SCA Spring拡張機能は、Java EEアプリケーションで使用できるオープン・ソースのSpringプロジェクトをJDeveloperで作成する機能の統合サポートを提供します。Spring JARファイルをライブラリとしてJDeveloperに追加し、Spring Bean構成ファイルを作成するウィザードと編集機能を追加します。この拡張機能によって、Spring JARファイルはSpring 2.5ライブラリとしてJDeveloperに追加されます。Spring Bean構成ファイルを作成するウィザードが追加され、関連するXSDとDTDがIDEに登録されて、Springを定義する生産性の高い編集作業が実現されます。
Springの詳細は、『Oracle Fusion Middleware Oracle WebLogic Server Springアプリケーションの開発と管理』を参照してください。
Oracle JDeveloper Weblogic SCA Spring拡張機能を使用するには、ダウンロードしてインストールする必要があります。この拡張機能で、次のものがJDeveloperに追加されます。
「新規ギャラリ」の「ビジネス層」に「Spring」カテゴリを追加できます。Spring Bean構成ファイルとWebLogic SCA構成を作成するオプションは、ここで使用できます。
Spring 2.5ライブラリが、SpringフレームワークのJARファイルおよびWebLogic SCAサポートとともにJDeveloperに追加されます。
Weblogic SCA Spring拡張機能を使用して、WebLogic SCA対応のプロジェクトを作成できます。これはJARファイルとしてデプロイでき、それをデプロイのためのEARファイルに、またはWARファイルとして含めることができます。
WebLogic SCAプロジェクトを開発するには、まずアプリケーションの制御ファイルとして動作するWebLogic SCA構成ファイルを作成します。このプロセスの一環として、JDeveloperでは必要なライブラリがサーバーにデプロイされるように、WebLogic SCAのJARまたはWARデプロイメント・ディスクリプタが構成されます。
WebLogic SCAアプリケーションを作成するには、次のようにします。
例22-2 「WebLogic SCA」ウィザードが行う処理
WebLogic SCA構成ウィザードを実行すると、次の処理が行われます。
spring-context.xmlというSCA定義ファイルがMETA-INF/jsca
に作成され、JDeveloperのXMLソース・エディタで開かれます。高度なXML編集フレームワークによって、編集がサポートされます。
プロジェクトにまだweb.xml
ファイルが含まれていない場合は、作成されます。
「新規ギャラリ」で選択したオプションによって、次のようになります。
JARデプロイメント・ディスクリプタがプロジェクトに追加され、weblogic-sca共有ライブラリに対する依存性がアプリケーション・レベルで追加されます。
WARデプロイメント・ディスクリプタがプロジェクトに追加され、weblogic-sca共有ライブラリに対する依存性がWebアプリケーション・レベルで追加されます。
例22-3 次のステップ
SCAプロジェクトを作成すると、次の操作が可能になります。
Oracle WebLogic Serverにアプリケーションをデプロイします。
JDeveloperの統合WebLogic Serverでアプリケーションをテストします。
WebLogic SCAプロジェクトを作成する際に作成されるSCA定義ファイルはspring-context.xml
という名前で、META-INF/jsca
の中に作成され、XMLソース・エディタで開かれます。
次の例は、spring-context.xml
ファイルの概要を示します。
<?xml version="1.0" encoding="windows-1252" ?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:util="http://www.springframework.org/schema/util" xmlns:jee="http://www.springframework.org/schema/jee" xmlns:lang="http://www.springframework.org/schema/lang" xmlns:aop="http://www.springframework.org/schema/aop" xmlns:tx="http://www.springframework.org/schema/tx" xmlns:sca="http://xmlns.oracle.com/weblogic/weblogic-sca" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-2.5.xsd http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd http://www.springframework.org/schema/jee http://www.springframework.org/schema/jee/spring-jee-2.5.xsd http://www.springframework.org/schema/lang http://www.springframework.org/schema/lang/spring-lang-2.5.xsd http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.5.xsd http://www.springframework.org/schema/tool http://www.springframework.org/schema/tool/spring-tool-2.5.xsd http://xmlns.oracle.com/weblogic/weblogic-sca META-INF/weblogic-sca.xsd"> <!--Spring Bean definitions go here--> </beans>
コメントは、Bean定義を入力する場所を示します。
XMLソース・エディタの機能、「構造」ウィンドウの機能、「コンポーネント」ウィンドウおよび「プロパティ」ウィンドウを使用して、XMLファイルの階層にナビゲートして編集します。
ソース・エディタの機能
ソース・エディタには、XMLファイルの編集に便利な多くの機能があります。
構文補完インサイトのXML固有の実装であるXMLコード・インサイト< を入力してしばらく待つと、JDeveloperでは入力場所に適したエントリ候補がポップアップ表示されます。選択したタグに必須の属性がある場合は、JDeveloperでは自動的に追加されます。
XMLソース・エディタには、エラーに赤い飾り線の下線が付くなど多くの機能があります。
「使用方法の検索」などのコンテキスト・メニューからオプションを選択でき、「使用方法」ログ・ウィンドウに要素の使用方法がすべて表示されます。「使用方法の検索」は「構造」ウィンドウからも使用できます。
「構造」ウィンドウの機能
「構造」ウィンドウでは、XMLファイルの階層をすばやく移動でき、編集機能もあります。
「構造」ウィンドウでノードを右クリックし、コンポーネントを追加します。
「構造」ウィンドウにエラー・メッセージが表示されます。
「コンポーネント」ウィンドウの機能
「コンポーネント」ウィンドウでタグを選択し、ソース・エディタまたは「構造」ウィンドウに直接ドラッグ・アンド・ドロップすると、spring-context.xmlファイルを作成できます。
注意:
タグをドロップできるのは、構文上正しい場所のみです。
デフォルトでは、使用可能なすべてのタグが「コンポーネント」ウィンドウに表示されます。表示されるタグを少なくするには、「すべてのページ」をクリックし、必要なタグのタイプのみを選択してください。たとえばWebLogic SCAのバインディングを使用する場合、「コンポーネント」ウィンドウの最上部にあるオプションと、リストされるコンポーネントが「EJBバインディング」およびWebサービス・バインディングになるように選択します。
「プロパティ」ウィンドウの機能
「プロパティ」ウィンドウでは、タグのプロパティを編集できます。
「プロパティ」ウィンドウでの変更は、ソース・エディタの表示で同期化されます。
特定のプロパティに関連する場合、値のリストが表示されます。
WebLogic SCAプロジェクトを作成した後、すぐに統合WebLogic Serverにデプロイし、アプリケーションをテストできます。
統合WebLogic Serverをデプロイするには、「アプリケーション」ウィンドウで、「アプリケーション」ウィンドウのプロジェクト・ノードの下にあるspring-context.xmlを右クリックして「実行」または「デバッグ」、または「プロファイラ」オプションのいずれかを選択します。
統合WebLogic Serverでアプリケーションを実行するときに行われる処理
統合WebLogic Serverをまだ起動していない場合は、デフォルト設定でデフォルトのドメインが自動的に作成され、サーバーが起動します。
アプリケーションが統合WebLogic Serverにデプロイされ、デプロイの進行状況を示すメッセージが「ログ」ウィンドウに表示されます。
「アプリケーション・サーバー」ウィンドウで、「IntegratedWebLogicServer」の下位にある「Webサービス」ノードおよび「EJB」ノードの下にデプロイされたサービスが表示されます。
作成したWebLogic SCAプロジェクトは、Oracle WebLogic Serverにデプロイできます。
JARファイルとWARファイルのどちらの作成を選択するかによって、プロセスは若干異なります。
注意:
WebLogic SCAアプリケーションをOracle WebLogic Serverにデプロイする前に、サーバーにWebLogic SCAをインストールする必要があります。詳細は、Oracle Fusion Middleware Oracle WebLogic Server Springアプリケーションの開発と管理でWebLogic SCA RuntimeのWebLogic Serverへのデプロイに関する章を参照してください。
WebLogic SCA WARファイルを含むアプリケーションをWebLogic Serverにデプロイするには、通常どおりアプリケーションをデプロイします。
WebLogic SCA JARファイルを含むアプリケーションをWebLogic Serverにデプロイするには、次のようにします。
例22-4 WebLogic Serverにアプリケーションをデプロイするときに行われる処理
必要な場合には、EARファイルが作成されます。
アプリケーションがWebLogic Server接続にデプロイされ、デプロイの進行状況を示すメッセージが「ログ」ウィンドウに表示されます。
「アプリケーション・サーバー」ウィンドウで、アプリケーション・サーバーの接続ノードの下位にある「Webサービス」ノードおよび「EJB」ノードの下にデプロイされたサービスが表示されます。
Weblogic SCA Spring拡張機能は、オープンソースのSpringフレームワークのための統合サポートを提供します。この拡張機能によって、多くのライブラリがJDeveloperに追加され、Springフレームワーク・プロジェクトの作成も追加でサポートされます
Weblogic SCA Spring拡張機能によって、SpringフレームワークのJARファイルを含むライブラリがJDeveloperに追加されます。Springフレームワーク・アプリケーションを開発するには、まずアプリケーションの制御ファイルとして動作するSpring Bean構成ファイルを作成します。
Spring Bean構成ファイルを作成するには、次のようにします。
「新規ギャラリ」の「ビジネス層」で「Spring」カテゴリを選択してSpring Bean構成を作成すると、Spring 2.5とCommons Logging 1.0.4のライブラリが自動的にプロジェクトに追加されます。ライブラリ定義にアクセスするには、「アプリケーション・サーバー」ウィンドウでプロジェクトのポップアップ・メニューから「プロジェクト・プロパティ」を選択し、「ライブラリとクラスパス」を選択します。
Spring Bean構成ファイルbeans.xmlがMETA-INF/jsca
に作成され、XMLソース・エディタで開かれます。高度なXML編集フレームワークによって、編集がサポートされます。
アプリケーションをデプロイする際に発生する可能性のある一般的な問題が多数あります。この項では、そうした問題と解決方法について説明します。統合WebLogic ServerとOracle WebLogic Serverのどちらにデプロイするときにも発生する問題と、どちらか一方のデプロイのみに固有の問題とに分かれています
この項では、統合WebLogic ServerとOracle WebLogic Serverのどちらにデプロイするときにも発生する問題に関する情報を提供します。
アプリケーションのデプロイと構成の変更が一度に複数のユーザーによって実行されないように、Oracle WebLogic Serverインスタンスがドメイン編集ロックを使用しています。このメッセージは、別のデプロイが同時に進行している(一度に許可されるデプロイは1つのみ)、または有効になっていないWebLogic Server管理コンソールでなんらかの変更があった場合に表示されます。まれですが、このメッセージは統合WebLogic Serverでアプリケーションを実行しているときにも表示されることがあります。
WebLogic Server管理コンソールで変更を有効にするには、次のようにします。
ドメイン構成ロック機能を有効または無効にするには、JDeveloperのインストールにあるWebLogic Serverのオンライン・ドキュメントから、または管理コンソールから使用できる管理コンソール・オンライン・ヘルプで、ドメイン構成ロックの有効化/無効化に関する項を参照してください。
統合WebLogic Serverへのデプロイ中にエラーが発生した場合には、管理コンソールを確認して問題の原因を特定できます。
この項では、統合アプリケーション・サーバーの実行に固有の問題について説明します。
以前のJDeveloperセッションで作成されて実行されたまま孤立したWebLogic Serverインスタンスをクリアする場合などに、統合アプリケーション・サーバーを停止したくてもJDeveloper内で停止できない場合は、jdeveloper-user-home/DefaultDomain/bin
に移動し、stopWebLogic.cmd
(Windowsの場合)またはstopWebLogic.sh
(Linuxの場合)を実行します。これで、統合アプリケーション・サーバーが正常にシャットダウンするため、それ以降にJDeveloperから統合アプリケーション・サーバーを起動しても競合しません。
「終了」ボタンを2回押すと、JDeveloperの制御下で(つまり孤立せずに)まだ稼働中のインスタンスを強制的にシャットダウンできます。
統合WebLogic Serverで複数のアプリケーションを実行する場合、メモリーが不足しjava.lang.OutOfMemoryError: PermGen space
例外が現れる場合があります。この例外を回避するには、MEM_MAX_PERM_SIZE
をデフォルトの128mから256m、512mまたはそれ以上に引き上げます。この設定は、jdeveloper-user-home/DefaultDomain/bin
にあるsetStartupEnv.cmd
(Windowsの場合)またはsetDomainEnv.sh
(Linuxの場合)で行います。
まず、前述のいずれかの方法で統合WebLogic Serverを停止する必要があります。
JDeveloperを新しい場所に再インストールする場合、ハードコードされたJDeveloperへの参照が統合アプリケーション・サーバーに使用されていることで、問題が起こる場合があります。次のいずれかの方法を実行する必要があります。
新しいシステム・ディレクトリが使用されるようにJDEV_USER_DIR
を設定します。これについては『Oracle Fusion Middleware Oracle JDeveloperのインストール』の「ユーザー・ホーム・ディレクトリの設定」に説明があります。
JDeveloperによって新しいシステム・ディレクトリが再生成されるように、古いシステム・ディレクトリを削除します。
「アプリケーション・サーバー」ウィンドウで、「IntegratedWebLogicServer」を右クリックして「デフォルト・ドメインの削除」を選択します。
この項では、Oracle WebLogic Serverへのデプロイに固有の問題について説明します。
通常、これはapplication-name-jdbc.xml
ファイルの<encrypted-password>
エントリのパスワードが空白になっているか、<encrypted-password>
エントリがないことが原因で起こります。
通常、これはapplication-name-jdbc.xml
ファイルの<encrypted-password>
エントリのパスワードが間違っていることが原因で起こります。
この場合、ログオンが拒否されます。Oracle WebLogic Serverのデータベース・ドライバweblogic.jdbcx.oracle.OracleDataSourceが使用されていることが原因です。このドライバはOracleで認証されていないため、使用しないでください。
データソースに対してターゲット・ドメインが選択されていることを確認してください。ウィザードの最後のパネルの前に「終了」をクリックした場合は、ターゲット・ドメインが選択されていません。
また、Javaコードに参照が使用されている場合は、Javaネーミング参照コールが正しいことを確認してください。たとえば、接続名がconnection1の場合、ネーミング参照はjava:comp/env/jdbc/connection1DS
となります。
停止しているサーバーには、アプリケーションを1回しかデプロイできません。
停止している同じサーバーに同じアプリケーションを再度デプロイしようとすると、デプロイが失敗して次のようなログ・メッセージが表示されます。
[03:29:47 PM] ---- Deployment started. ---- [03:29:47 PM] Target platform is (Weblogic 10.3). [03:29:47 PM] Retrieving existing application information [03:29:47 PM] Running dependency analysis... [03:29:47 PM] Building... [03:29:50 PM] Deploying 2 profiles... [03:29:50 PM] Wrote Web Application Module to /path/oracle/jdeveloper/jdev/mywork/Application1/Project1/deploy/webapp1.war [03:29:50 PM] Wrote Enterprise Application Module to /path/oracle/jdeveloper/jdev/mywork/Application1/application1.ear [03:29:50 PM] Redeploying Application... [03:29:50 PM] [Deployer:149034]An exception occurred for task [Deployer:149026]deploy application application1 on Server-1.: [DeploymentService:290049]Deploy failed for id '1,244,759,390,503' since no targets are reachable.. [03:29:50 PM] Weblogic Server Exception: java.lang.Exception: [DeploymentService:290049]Deploy failed for id '1,244,759,390,503' since no targets are reachable. [03:29:50 PM] See server logs or server console for more details. [03:29:50 PM] java.lang.Exception: [DeploymentService:290049]Deploy failed for id '1,244,759,390,503' since no targets are reachable. [03:29:50 PM] #### Deployment incomplete. #### [03:29:50 PM] Remote deployment failed
アプリケーションを正常に管理対象サーバーにデプロイすると、デプロイメント・ウィザードによってこのデプロイ操作が履歴に保存されるため、後から同じ操作を実行できます。ただし、管理対象サーバーをOracle WebLogic Serverドメインから削除した場合にデプロイ履歴上の操作を使用して後からデプロイしようとすると、デプロイが失敗して次のようなログ・メッセージが表示されます。
[02:38:40 PM] ---- Deployment started. ---- [02:38:40 PM] Target platform is (Weblogic 10.3). [02:38:40 PM] Retrieving existing application information [02:38:40 PM] #### Deployment incomplete. #### [02:38:40 PM] [J2EE Deployment SPI:260013]Target array passed to DeploymentManager was null or empty.
JDeveloperにプロキシが設定されている環境で、ネットワークDNSサーバーで認識されていないマシン上で実行されているサーバーにデプロイすると、デプロイが失敗してHTTPエラー・コード502が表示されます。これは、リクエストの転送先がプロキシで認識されていないためです。これは、マシン名によって参照されているlocalhost上のサーバーにデプロイする際にも発生することがあり、一般的にはSOA開発のときに発生します。
これを回避するには、「プリファレンス」ダイアログの「Webブラウザとプロキシ」ページで、プロキシ設定の「例外」リストにマシンを追加するか、接続にHTTPプロキシ・サーバーを使用しないようにします。
この項では、統合WebLogic ServerとOracle WebLogic Serverのどちらにデプロイするときにも発生する問題に関する情報を提供します。
wsadmin.bat
のパスに空白があると、WindowsへのWebSphereのデプロイメントは機能しません。「WebSphere Serverへの接続」を参照してください。