プロダクション業務ガイド

チーム開発環境の管理

この章では、WebLogic Portal 開発に対する共通の環境をコンフィグレーションおよび管理する方法について説明します。共通の開発環境により、開発者は同じ WebLogic Portal ドメイン、データベース、アプリケーション コンフィグレーションを共有し、ソース コントロール システムでのこれらの要素を保持することができます。きちんと計画されたチーム開発により、WebLogic Portal アプリケーションの開発、ビルド、および更新をすばやく、一貫性のある方法で行うことができます。

この章の内容は以下のとおりです。

はじめに

WebLogic Portal のチーム開発環境のコンフィグレーションに必要な基本のタスクには、次のものがあります。

これらのタスクについては、以下の節で説明します。

ソース コントロール ベンダの選択

WebLogic Portal Web サイトのチーム開発は、適切なソース コントロールを中心として行われます。ソース コントロール システムを正しく利用すれば、チーム メンバーが 1 つになること、開発チームの規模をすばやく拡大できること、データ損失の防止などの、多数の利点がもたらされます。

ソース コントロールのプロバイダには、CVS、Subversion (SVN)、Perforce、StarTeam、Visual Source Safe (VSS)、PVCS などの、さまざまなものがあります。この章は、このようなベンダのうちどれを使用する場合にも役立ちます。ただし、コードの格納に関しては、ベンダはそれぞれ異なる特徴を持っています。ポータル アプリケーションをチーム開発するためのソース コントロール管理システムを選択するときに考慮すべき重要な事項の一つに、ファイルの自由なチェック アウト モデルのサポートがあります。なぜなら、ドメインとアプリケーションのファイルの多くは、ソース コントロール管理へのチェック インが必要であり、またサーバによる書き込みが可能でなければならないからです。自由なチェックアウト モデルとは、複数のユーザがチェックアウトでき、同時にファイルを編集できることを意味します。すなわち、個々のユーザは、ファイルをチェックアウトするとき、他のユーザに対してファイルを「ロック」しません。

共有 WebLogic Portal ドメインの作成

この節では、共有 WebLogic Portal ドメイン作成の基本的手順、および次のトピックについて説明します。

WebLogic Portal ドメインとは

WebLogic Portal ドメインは、ポータルを構築する基盤です。ドメインには、サーバ環境を定義し実行するコンフィグレーション ファイル、データベース、およびスクリプトが含まれ、デフォルトのセキュリティ レルムと事前に定義されたシステム管理者を提供し、サーバ管理ツールを提供します。ドメインには、ポータルと関連機能を構築するためのファイルとサービスも含まれます。

基本的なドメイン インフラストラクチャは、1 つの管理サーバとオプションの管理対象サーバおよびクラスタで構成されます。これらのコンポーネントの詳細、およびドメインの詳しい説明については、WebLogic Server ドキュメントの『コンフィグレーション ウィザードを使用した WebLogic ドメインの作成』を参照してください。

チーム開発環境では、ドメイン関連ファイルがソース コントロールに保存され、個々の開発マシンにチェックアウトされます。チーム メンバーは、ソース コントロールを使用してこれらのドメイン ファイルを共有します。これによって、既存のデプロイ済みアプリケーションに対するすべての変更内容、新規アプリケーションの追加、およびコンフィグレーション ファイルに格納されているその他の設定やスクリプトを共有できるようになります。

始める前に

チームのすべての開発者は、最初に、開発マシンに WebLogic Portal をインストールする必要があります。必須ではありませんが、すべての開発者が、共有のホーム ディレクトリに WebLogic Portal をインストールすることをお勧めします。

WebLogic Portal ドメイン テンプレートの作成

チーム メンバーに共通のコンフィグレーション ドメインを配布する方法としては、ドメイン テンプレートを作成し、それをソース コントロールにチェックインすることをお勧めします。

ドメイン テンプレートは、新しいドメインを作成するのに使用されます。ドメイン テンプレートは、インフラストラクチャ コンポーネント、アプリケーション、サービス、セキュリティ オプション、一般環境とオペレーティング システム パラメータなど、ドメイン内のリソースの完全なセットを定義します。既存のテンプレートまたは既存のドメインから、ドメイン テンプレートを作成できます。共有ドメイン テンプレートを指定すると、チーム内の全開発者は、個々の開発マシンで同じドメイン コンフィグレーションを効率的に作成できます。

ドメイン テンプレートの作成の詳細については、WebLogic Server ドキュメントの「WebLogic Configuration Template Builder によるコンフィグレーション テンプレートの作成」を参照してください。

共有ドメインの作成

ドメイン テンプレートが作成されて、ソース コントロールにチェックインされると、各開発者は、テンプレートをチェックアウトして、自分独自のローカル ドメインを作成できます。開発者が同じテンプレートを使用してドメインを作成できるので、ドメインのコンテンツは同等になります。

各開発者はドメイン テンプレートを使用し、WebLogic Configuration Wizard またはスクリプトを使ってローカル ドメインを作成します。Configuration Wizard の使用の詳細については、WebLogic Server ドキュメントの「コンフィグレーション ウィザードを使用した WebLogic ドメインの作成」を参照してください。ドメインと共にインストールされるファイルの概要については、WebLogic Server ドキュメントの「ドメイン コンフィグレーション ファイル」を参照してください。

WebLogic Server の起動

ドメインの DOMAIN_ROOT/bin/startWeblogic コマンドを使用して WebLogic Server を起動します。

ドメインのコンフィグレーションと調整

実行中のサーバで、ドメインをコンフィグレーションできます。WebLogic Server Administration Console (http://server:port/console) を使用して、必要なデータ ソースの追加など、開発作業をサポートするようにドメインを設定できます。サーバ コンフィグレーションの詳細については、WebLogic Server ドキュメントの「BEA WebLogic Server システム管理」に関する説明を参照してください。

開発ドメインの一般的な調整作業には、(より詳しいコンソール出力や、JVM メッセージのコンソールへの出力のために) サーバのロギング モードを Warn から Info に変更することなどがあります。また、ログ ファイルの最大サイズは制限できます。

行った変更は、DOMAIN_ROOT/config/config.xml ファイルに保存されます。このファイルをソース コントロールにチェックインして、開発チームのメンバーと共有できます。ただし、config.xml ファイルには、各開発者がローカルに変更する必要があるハード コード化されているパスが含まれています。このファイルを共有する 1 つの方法は、文字列置換テンプレートを作成してチェックインし、各開発者がローカルに実行して固有の config.xml ファイルを作成できるスクリプトを提供することです。

データベースの管理

WebLogic Portal のコンフィグレーション情報の多くはデータベース内に格納されますが、開発チームがこのコンフィグレーションへのアクセスを共有しなければならないこともあります。ただし、WebLogic Portal は、1 つのポータル サーバの複数のインスタンスを単一の同じデータベース サーバまたはデータベース スキーマに対して実行することはサポートしていません。WebLogic Portal ドメインに対するデフォルトのデータベースは PointBase ですが、開発作業には、エンタープライズ品質のデータベースが必要な場合があります。

WebLogic Portal と一緒に配布される評価版の PointBase によるサイズ制限に関する情報を含め、WebLogic Portal に対するデータベース管理の詳細については、『WebLogic Portal のデータベース管理ガイド』を参照してください。PointBase データベースの扱いに関する情報については、「PointBase データベースの使用」を参照してください。

この節の内容は、次のとおりです。

エンタープライズ品質データベースを使用した開発

PointBase データベースをバイナリ ファイルとして開発者間で共有するのではなく、Oracle や SQL Server などのエンタープライズ品質データベースを使用して、各開発者が自分専用のポータル データベースを使用して作業することが一般的です。

各開発ドメインは、ドメイン テンプレートを通じて、DOMAIN_HOME/config/jdbc ディレクトリの複数の XML ファイルに一覧表示されている特定のデータベースを使用するようにコンフィグレーションされます。詳細については、『WebLogic Portal のデータベース管理ガイド』を参照してください。

開発とプロダクションで異なるデータベースを使用

一般に、ステージングとプロダクションで使用する予定のエンタープライズ品質の DBMS と同じものを、開発でも使用することをお勧めします。たとえば、Oracle でアプリケーションをデプロイする予定の場合には、アプリケーションも Oracle で開発することをお勧めします。この方法により、パフォーマンスが向上し、データのベースラインの保守が簡単になります (データベース管理者の適切なサポートとスクリプトが必要)。

開発であるタイプのデータベースを使用し、ステージングとプロダクションに別のデータベースを使用し、伝播ツールを使ってそれらのデータベース間でデータを移動することも可能です。この場合、開発者は、開発で PointBase を使用し、ステージングとプロダクション システムでは Oracle のようなエンタープライズ品質データベースを使用できます。伝播ツールを使用して、開発システムからデータベース インベントリをエクスポートして、それをステージングまたはプロダクション システムにインポートできます。伝播ツールの使用の詳細については、「Workshop for WebLogic 伝播ツールの使用」を参照してください。

データベースに変更を加えるタイミングの確認

一般に、WebLogic Portal Administration Console を使用して行うアクティビティのほとんどは、データベースに永続的に保存されますが、資格は組み込み LDAP に永続的に保存されます。ただし、テスト ユーザを、テスト ユーザに割り当てられているユーザ プロパティと一緒に使用して開発する場合もあります。

このようなプロパティはデータベースに格納されます。さらに、サービス管理コンフィグレーションはデータベースではなく、アプリケーションのデプロイメント計画に保持されます。BEA リポジトリに格納されている実際のコンテンツはデータベース内にありますが、コンテンツ リポジトリのコンフィグレーションはデータベースには保持されません (ファイル システム リポジトリを使用している場合、コンテンツ メタデータのみがデータベースに格納されます)。

資格の詳細については、『WebLogic Portal のセキュリティ ガイド』を参照してください。

PointBase データベースの使用

PointBase に対する開発ライセンスは、WebLogic Portal でインストールされます。開発ライセンスでは、データベース サイズは 30MB に制限されています。この制限を増やすには、フル ライセンスを購入する必要があります。また、PointBase はデータベースを使用するにつれて増大するバイナリ ファイルにデータを格納します。チーム環境でバイナリ ファイルを処理することについては、「ソース コントロールでのバイナリ ファイルの管理」を参照してください。

ポータル アプリケーションの作成と共有

ポータル ドメインをコンフィグレーションしたら、開発チームのすべてのメンバーにより共有される新しいポータル アプリケーションを作成する必要があります。

ドメイン作成のように、アプリケーション作成にはいくつかの手順があります。これらの手順はこの節で説明されています。以下のものが含まれます。

Eclipse ワークスペース ディレクトリの作成または配置

Workshop for WebLogic で作成したすべてのプロジェクトは、ワークスペース ディレクトリ内に作成されます。ワークスペースとプロジェクトの作成の詳細については、『WebLogic ポータル開発ガイド』を参照してください。

ポータル EAR プロジェクトの作成

Workshop for WebLogic を使用して、1 つまたは複数のポータル EAR プロジェクトを作成します。EAR プロジェクトは主に Web アプリケーションと J2EE 共有ライブラリを参照するコンフィグレーション ファイルで構成されています。

EAR プロジェクトを作成するとき、図 2-1 に示すように、WebLogic Portal ファセットのセットなど、プロジェクトに含めるプロジェクト ファセットを選択します。

ファセットは特定の機能に対して必要とされる J2EE 共有ライブラリと IDE 機能のセットをグループ化するのに便利な方法です。たとえば、Admin Console ファセットは、WebLogic Portal Administration Console をデプロイし実行するのに必要な J2EE 共有ライブラリをグループ化します。ファセットを含めない場合は、それを選択解除できます。一部のファセットは他のファセットに依存します。依存関係があるファセットを削除しようとすると、ダイアログ ボックスが警告を表示し、その特定の変更を禁止します。

ポータル EAR プロジェクトの作成の詳細については、『WebLogic ポータル開発ガイド』を参照してください。

ポータル Web プロジェクトの作成

Workshop for WebLogic を使用して、ポータル Web プロジェクトを作成します。ポータル Web プロジェクトには、ポータルのソース コードと、プロジェクトにより使用される J2EE 共有ライブラリを参照するコンフィグレーション ファイルが含まれます。

Web プロジェクトを作成するとき、図 2-2 に示すように、WebLogic Portal ファセットなど、プロジェクトに含めるプロジェクト ファセットを選択します。

書き込むアプリケーション コードは、Web プロジェクト内のファイルに保存されます。一般的なアプリケーションでは、コードは Web プロジェクトの WebContent ディレクトリに配置されます。BEA により供給されるドメインとアプリケーション特定コードは、J2EE 共有ライブラリに格納され、アプリケーションにより参照されます。

ポータル Web プロジェクトの作成の詳細については、『WebLogic ポータル開発ガイド』を参照してください。

ポータル アプリケーションのチェックイン

書き込むコードは、BEA が J2EE 共有ライブラリに提供するドメインとアプリケーション コードから、物理的に分離されます。必要なのは、自分または自分のチームのメンバーが書き込んだアプリケーションコードをソース コントロール システムに格納することだけです。デフォルトでは、アプリケーション コードは Web アプリケーションの WebContent ディレクトリに配置されます。Java ソース コードは、src ディレクトリに配置されます。Eclipse は、プロジェクト設定およびプロジェクト内のその他のコンフィグレーションも格納します。ファイルには以下のものが含まれます。

新しいコンポーネントが作成されるので、これらの新しいコンポーネントの多くは、ソース コントロールにチェックインする必要があります。開発者は、作成されているファイルのうちどれが、ソース コントロールで共有する必要があるのかを知る必要があります。

ソース コントロールから、Web プロジェクトに固有の Java 出力ディレクトリを除外します。一般に、これらのディレクトリには、build または bin と名前が付いています。また、ハードコード化されたパスを含むファイルのチェックインは避けます。

デプロイメント中に共通で更新されて、ソース コントロールにチェックインする必要がある 3 つのファイルには、次が含まれます。これらのファイルは、エンタープライズ アプリケーションの META-INF ディレクトリに配置されます。

Workshop for WebLogic アプリケーションのチェックアウト

ソース コントロール管理と Workshop for WebLogic アプリケーションを使用して作業するときの基本的な考え方は、アプリケーションのチェック アウト、ビルドの開始、およびエラーなしでのサーバの起動を開発者が実行できるようにしなければならないというものです。

EAR プロジェクトが Workshop for WebLogic によってドメインにデプロイされるとき、それはドメインの DOMAIN_ROOT/config/config.xml に登録されます。このデプロイメントは、サーバが起動されたときと、アプリケーションがビルドされたときに自動的に行われます。この時点で、アプリケーションは config.xml の新しい XML ブロックとして追加されます。

コード リスト 2-1 に、myPortalEAR という名前のエンタープライズ アプリケーションについて config.xml に追加されるブロックを示します。

<app-deployment>
    <name>myPortalEAR</name>
    <target>AdminServer</target>
    <module-type>ear</module-type>
    <source-path>D:\users\projects\applications\myWorkspace\.metadata\.plugins\
        org.eclipse.core.resources\.projects\myPortalEAR\beadep
    </source-path>
    <security-dd-model>DDOnly</security-dd-model>
</app-deployment>

Workshop for WebLogic によってドメインの config.xml が自動的に更新されるので、アプリケーション名の XML ブロックが含まれる config.xml をソース コントロールに再びチェック インする必要はありません。代わりに、開発者はアプリケーションをチェック アウトし、ビルドを行い、このアプリケーション参照がない状態のドメインでサーバを起動します。開発者のアプリケーションはサーバに公開されます。コンポーネントの追加または削除が必要な場合、Workshop for WebLogic は自動的にそれを更新します。

ソース コントロールからアプリケーションをチェックアウトしたあと、各開発者はそれを Workshop for WebLogic にインポートする必要があります。これを実行するには、[ファイル｜インポート] を選択します。[インポート] ダイアログで、[既存プロジェクトをワークスペースへ] を選択します。次に、オンライン ヘルプの指示に従い、プロジェクトの位置を突き止めてインポートします。

チーム環境での J2EE 共有ライブラリの使用

この節では、次のトピックについて説明します。

概要

J2EE 共有ライブラリは、J2EE アプリケーションまたは Web アプリケーションの再利用可能部分です。エンタープライズ アプリケーション レベルでは、J2EE 共有ライブラリは、Java クラス、EJB デプロイメント、および Web アプリケーションを含むことができる EAR ファイルです。Web アプリケーション レベルでは、J2EE 共有ライブラリは、サーブレット、JSP、タグ ライブラリを含むことができる WAR ファイルです。標準 EAR または WAR ファイルと、J2EE 共有ライブラリ間の違いは、参照によって複数の共有ライブラリを 1 つのアプリケーションに含むことができることと、複数のアプリケーションが単一の J2EE 共有ライブラリを参照できることです。

WebLogic Portal 開発チームの共有ライブラリの最も有効な側面の 1 つは、チームによって開発されるコードと BEA により配布されるコードが物理的に分離されたままであるということです。WebLogic Portal の更新またはパッチが共有ライブラリとして配布されるとき、実行する必要があるのは、インストール ディレクトリに新しいライブラリを追加することだけです。参照するアプリケーションと、開発者によって書き込まれるコードは、アプリケーションが再デプロイされるときに自動的に新しいモジュールをピックアップします。

優先に関する共有ライブラリ ルール

WebLogic Portal アプリケーションは、複数の共有ライブラリを参照できます。同様に、ライブラリは他のライブラリを参照できます。J2EE 共有ライブラリ コードと固有のアプリケーション コードが実行時にアセンブルされるので、潜在的な衝突を解決するためのルールが存在している必要があります。これらのルールは以下のとおりです。

これらの優先ルールは、開発チームにとって重要な意味があります。たとえば、チームは CSS ファイルのような特定のファイルを J2EE 共有ライブラリからコピーすることを選択できます。開発者が開発分野でこれらのファイルを変更する場合、その変更は、元の共有ライブラリ バージョンに優先します。

デプロイメント記述子と共有ライブラリ

コード、その他のモジュール、およびリソースの他に、共有ライブラリにはデプロイメント記述子が含まれます。デプロイメント記述子は、ライブラリのコンテンツを説明します。次の例は、J2EE 共有ライブラリを参照するエンタープライズ アプリケーションの基本構造を示しています。

この例では、コード リスト 2-2 に示されている構造がある myApp.ear というエンタープライズ アプリケーションがあると仮定します。アプリケーションには、2 つのモジュールの myEjb.jar と myWebApp.war、および myClasses.jar 内の追加の Java コードが含まれます。

META-INF/weblogic-application.xml 記述子で太字で表示されている要素に注意してください。<library-ref> 要素が AppLibOne という J2EE 共有ライブラリへの参照を指定します。

コード リスト 2-3 は、エンタープライズ アプリケーションによって参照される実際の J2EE 共有ライブラリの AppLibOne.ear を示しています。ライブラリには、太字で表示されている META-INF/MANIFEST.MF ファイルが含まれており、それにはライブラリ名とバージョン情報が含まれています。共有ライブラリがデプロイされたら、このマニフェストを通じて、サーバがそれを識別し、デプロイされているアプリケーションにそれをアセンブルすることができます。

コード リスト 2-4 は、ライブラリ内のデプロイメント記述子がすべて読み込まれて解釈された後の、最終的にデプロイされるアプリケーションの効率的なコンフィグレーションを示しています。サーバは 2 つの EJB JAR ファイルをデプロイします。myEjb.jar ファイルは myApp.ear アーカイブから、別の libEjb.jar は J2EE 共有ライブラリから取得します。さらに、myApp の myClasses.jar 内のクラスが、AppLibOne J2EE 共有ライブラリ内の code.jar ファイルからのクラスをオーバーライドするように、アプリケーションのクラスパスが順序付けされます。

ポータル リソースの共有 : サンプル シナリオ

共有ライブラリは、開発チームが開発したポータル リソースを他のチームと共有するのに便利なメカニズムを提供します。

この節では、次のトピックについて説明します。

はじめに

たとえば、1 つのチーム環境が、1 つまたは複数のポートレット開発チームと、ポータル全体を組み立てて維持する責任があるチームで構成されていると仮定します。図 2-3 は例を示しています。ポータル開発チームは、共有ライブラリ (WAR) ファイルを、ポートレット開発チームに配布します。ライブラリ ファイルには、ポータルと、ポータル ルック アンド フィールのような関連リソースが含まれます。ポートレット チームは、このファイルを受け取ってそれを共有ライブラリとしてプロジェクト スペースにインポートし、それをチーム メンバーが利用できるようにして、ポートレットをテストするためのポータルを提供します。

ポートレット チームはポートレットのセットを構築後、共有ライブラリ (WAR) ファイルをポータル チームに戻します。ポータル チームは WAR を受け取り、それをモジュールとしてインポートし、ポートレットをポータルに追加します。J2EE 共有ライブラリの作成の詳細については、WebLogic Server ドキュメントの「J2EE ライブラリおよびオプション パッケージの作成」に関する説明を参照してください。

共有するリソースのパッケージ化

共有ライブラリとしてリソースを共有するのに含まれる基本の手順には、次が含まれます。

共有リソースの受け取りと組み込み

共有ライブラリ WAR ファイルを受け取ると、ポータル チームは適切なコンフィグレーション ファイル内の共有ライブラリ WAR ファイル (および、オプションで、そのバージョン番号) を参照します。共有ライブラリ WAR ファイルへの参照は、ポータル Web アプリケーションの weblogic.xml ファイルおよびドメインの config.xml ファイルに移動します。

weblogic.xml ファイルにはライブラリ名 (およびオプションでバージョン番号) が含まれ、ドメインの config.xml ファイルには共有ライブラリ WAR ファイルの実際のパスが含まれます。J2EE 共有ライブラリの参照については、「チーム環境での J2EE 共有ライブラリの使用」を参照してください。

共有ライブラリの Workshop for WebLogic へのインポート

次のように、プロジェクトの Java ビルド パスにライブラリを追加する必要があります。

デプロイされたアプリケーションへの共有ライブラリのインポート

ポートレットをデプロイされたポータルに組み込むため、ポータル チームは WebLogic Server Console を使用して、WAR ファイルを J2EE 共有ライブラリとしてデプロイします。

WebLogic Portal コーディングのベスト プラクティス

この節では、チーム開発環境でのポータル アプリケーション ソース コードの管理について説明します。

この節では、以下について説明します。

Java プロジェクトの共有

多数の汎用 Java ライブラリをポータルで使用する場合は、Java ライブラリを、ポータル エンタープライズ アーカイブ内の Java プロジェクトに格納するか、または J2EE 共有ライブラリとしてパッケージ化することをお勧めします。このようにすれば、サーバの複数のインスタンスに Java ライブラリを移植することが可能になり、ライブラリを再利用および共有するためのパッケージ化も容易になります。

ベスト プラクティスは、エンタープライズ アプリケーションの APP-INF/lib ディレクトリに Java ライブラリを含む JAR ファイルを配置するか、J2EE 共有ライブラリとして JAR ファイルをコンフィグレーションすることです。J2EE 共有ライブラリの作成の詳細については、WebLogic Server ドキュメントの 「J2EE ライブラリおよびオプション パッケージの作成」に関する説明を参照してください。

クロスプラットフォーム開発のサポート

クロスプラットフォーム環境での開発とデプロイにおけるコーディングでは、以下のベスト プラクティスに従ってください。

ポータル コンポーネントの定義ラベルの編集

定義ラベルと呼ばれる一意の識別子は、Workshop for WebLogic でポータルに追加する各ブック、ページ、およびポートレットに対して自動的に生成されます。プロパティ ビューで Workshop for WebLogic のコンポーネントに対する定義ラベルを表示できます。

複数の開発者が新しいポータル コンポーネントを作成していると、異なるコンポーネントに対して同一の定義ラベルが自動的に生成される場合があります。定義ラベルの重複を避けるには、命名規約を使用して新しいコンポーネントごとに手動で定義ラベルを変更します。

定義ラベルの変更については、『ポータル開発ガイド』を参照してください。

クラスタ コンフィグレーションのテスト

作成したコードは、クラスタ環境において十分にテストしてください。また、セッション データが管理可能なサイズを超えないように維持し、クラスタ全体でのセッション共有をサポートするように Web アプリケーションをコンフィグレーションします。セッション データがシリアライズ可能であることを確認します。クラスタ化情報については、「ポータル クラスタのコンフィグレーション」を参照してください。

ソース コントロールでのバイナリ ファイルの管理

WebLogic Server ドメインを正しく機能させるには、ドメインのバイナリ ファイルの多くをソース コントロール管理にチェック インする必要があります。データベース ファイルのようなこれらのファイルの一部は、WebLogic Portal 開発の過程で変更できます。

このようなバイナリ ファイルは、ユーザの操作や、インデックス ファイルの増加などのさまざまな理由で変更されることがあります。これらのファイルがどのようなものか、どのような理由で変更されるか、いつチェックインおよびチェックアウトされるかを理解することが重要です。

この節では、ソース コントロール管理で特定のバイナリ ファイルを、いつ更新する必要があるかを判断する方法を説明します。これらのファイルの一部には、LDAP ファイル、セキュリティ関連ファイル、およびデータベース コンフィグレーション ファイルが含まれます。

この節では、次のトピックについて説明します。

バイナリ ファイルを扱うための一般的な手順

ソース コントロールの中でバイナリ ファイルを共有できるようにするには、ファイルに変更を加えるときに常に同じプロセスに従う必要があります。プロジェクトのライフサイクルの間に、マージで衝突が発生する可能性を減らすには、バイナリへの変更を、単一のユーザが一貫的に実行することをお勧めします。

何らかの理由で、ソース コントロールでドメイン バイナリ ファイルを変更する必要がある場合、次の手順に従います。

ユーザ、グループ、ロール、および資格の更新

開発における一般的なアクティビティの 1 つに、システムのテストに使用する基本的なユーザとグループのセットの作成があります。デフォルトでは、WebLogic Server はユーザとグループを PointBase RDMBS に格納します。ユーザの資格をサポートするために、LDAP ポリシー データとデータベース データ間に関連性が存在します。組み込み LDAP サーバは WebLogic Portal で提供されます。この LDAP サーバのデータ ストアは、ファイル システムの DOMAIN_HOME/servers/AdminServerName/data/ldap ディレクトリ内に永続的に保存されます。

BEA の LDAP サーバについては、WebLogic Server ドキュメントの「組み込み LDAP サーバの管理」を参照してください。

LDAP サーバには、ロール、セキュリティ ポリシーなど、チーム メンバーと共有する必要がある情報が含まれているので、LDAP ディレクトリ内のファイルを、バックアップ ファイルおよびログ ファイルを除いて、ソース コントロールにチェックインします (「表 2-2 ソース コントロールから除外するドメイン ファイル」を参照)。

プロジェクト開発の進行中に、既存のユーザ、グループ、ロール、および資格が変更されることもあります。ユーザ、グループ、ロール、および資格を WebLogic Portal Administration Console を使ってコンフィグレーションできます。データベースと LDAP 変更をソース コントロールに保持することが重要です。

資格の詳細については、『WebLogic Portal のセキュリティ ガイド』を参照してください。ユーザとグループの詳細については、『WebLogic Portal のユーザ管理ガイド』を参照してください。WebLogic Portal Administration Console の使用方法については、『WebLogic Portal の管理ツール ガイド』を参照してください。

その他のセキュリティ関連ファイルの更新

ドメイン内に存在するその他の重要なセキュリティ ファイルは、SerializedSystemIni.dat、DefaultAuthenticatorInit.ldift、DefaultAuthorizerInit.ldift、および DefaultRoleMapperInit.ldift ファイルです。これらのファイルは DOMAIN_HOME/security ディレクトリに配置されます、ここで DOMAIN_HOME はドメインのルート ディレクトリです。

これらのファイルには、ドメインの起動に必要となる重要なセキュリティ情報が格納されています。これらのファイルは、一般に、開発中に変更されることはありませんが、サーバを起動するにはこれらのファイルが存在している必要があります。DOMAIN_HOME/servers/AdminServer/security/boot.properties ファイルには、ドメインを起動するための暗号化されたユーザ名とパスワード情報が含まれています。このファイルは必須ではありませんが、一般に、開発環境で認証の必要なしにサーバ起動を許可するために使用されます。

セキュリティの詳細については、『WebLogic Portal のセキュリティ ガイド』を参照してください。

ファセットのコンフィグレーション

ほとんどの場合、開発チームおよびサード パーティ開発チーム間でリソースを共有するために、共有 J2EE ライブラリを使用することで十分です。しかし、場合によっては、開発した機能のバンドルを含み、Workshop for WebLogic に新しいプロジェクトを作成するとき開発者によってインストールできるプロジェクト ファセットを開発する場合があります。

WebLogic Portal 9.2 より以前は、プロジェクト テンプレートを作成し、それを WebLogic Workshop からプロジェクトに含めることができました。WebLogic Portal 9.2 の同等の機能は Eclipse プラグインを使用して処理されます。Workshop for WebLogic は (Eclipse Web Tools Platform (WTP): http://www.eclipse.org/webtools からの) ファセットの概念を使用します。

ファセットは、プロジェクトに追加できる機能のセットです。ファセットは、新しいプロジェクトを作成するとき、ウィザードに表示されます。ファセットを選択すると、Workshop for WebLogic によりファセットのコンポーネントのすべてがプロジェクトにインストールされます。

ファセット開発は、機能を直接 Workshop for WebLogic に統合するパートナーや開発者に対する次のステップです。

WebLogic Portal は、プロジェクト機能拡張ポイントに対するライブラリ モジュールを含み、それによって、1 つまたは複数の J2EE 共有ライブラリを含むようにファセットを定義し、他のリソースはプロジェクト クラスパスに移動するように定義できます。そのようなプラグインを開発することは簡単なので、コードを含む必要はありません。一般に、必要なのは、plugin.xml ファイルを書き込むことだけです。もちろん、プラグインでビュー、エディタ、または他のツールに対するコード含めることができますが、単にファセットを Workshop for WebLogic に表示させる場合は、コードは必要ありません。

代替のドメイン共有方法

この節では、「共有 WebLogic Portal ドメインの作成」で説明した、ポータル ドメインを作成し、チームメンバー間で共有するという推奨されている方法では十分でない場合の代替の方法を説明します。

この節では、次のトピックについて説明します。

BEA ホーム ディレクトリの判断

所定のシステムに WebLogic Platform ソフトウェアがインストールされるディレクトリを、BEA ホーム ディレクトリと呼びます。図 2-4 にホーム ディレクトリの例を示します。チーム環境にある各開発マシンには、固有の BEA ホーム ディレクトリがあります。

Workshop for WebLogic アプリケーションとドメインはそれぞれ BEA ホーム ディレクトリを参照するので、BEA ホーム ディレクトリをどこに配置するかを注意深く検討することが重要です。最も単純なコンフィグレーションは、チーム環境のすべてのマシンがまったく同じ BEA ホーム ディレクトリ (同じドライブ/ディレクトリ名) を使用する場合です。これ以外の場合は、異なる BEA ホーム ディレクトリの場所を管理するための方針を選択する必要があります。これらの方針については、この節で説明されています。

BEA ホーム ディレクトリの重要性

ドメインの Configuration Wizard を使用して新しいポータル ドメインを作成するときに、そのドメインでどの BEA ホーム ディレクトリを参照するかを選択します。このディレクトリに対する物理的なパスは、各開発マシンのポータル ドメインの config/config.xml ファイル、startWeblogic.cmd のようなドメイン バッチ スクリプト、およびその他のドメインファイルに含まれます (完全なリストについては、表 2-1 を参照)。

たとえば、コード リスト 2-5 は、config.xml ファイルの一部を示しています。この例では、<source-path> 要素は、D:\myBeaHome のサブディレクトリにある J2EE 共有ライブラリ ファイルを指し示しています。この場合 D:\myBeaHome が BEA ホーム ディレクトリです。

<library>
    <name>p13n-app-lib#9.2.0@9.2.0</name>
    <target>AdminServer</target>
    <source-path>D:\myBeaHome\weblogic92\common\deployable-libraries\p13n-app-lib.ear
    </source-path>
    <deployment-order>1</deployment-order>
    <security-dd-model>DDOnly</security-dd-model>
  </library>

config.xml および他のドメイン ファイルがソース コントロールで共有される場合、すべてのチーム メンバーが、これらのファイルにハードコード化されている BEA ホーム ディレクトリ パスに WebLogic Server をインストールしなければならないか、別の方針を使用する必要があります。さまざまなマシンで、さまざまな BEA ホーム ディレクトリを保持するための方針については、次の節の「チームの複数の BEA ホーム ディレクトリの場所の管理」で説明されています。

表 2-1 は、ハードコード化された BEA ホーム ディレクトリ パスを含むドメインにあるファイルのすべてを一覧表示します。表 2-1 に表示されているファイルは、ドメインのルート ディレクトリを基準にしています。

次の節では、チーム メンバー全員が同じ BEA ホーム ディレクトリを使用することが不可能な場合の方法を説明します。

チーム メンバー全員が同じ BEA ホーム ディレクトリを使用できる場合は、「ポータル ドメインの作成と共有」に進んでかまいません。

チームの複数の BEA ホーム ディレクトリの場所の管理

コンテンツが同等のドメインを、チームメンバーと、別の BEA ホーム ディレクトリを使って共有するためのさなざまな方法があります。これらのオプションについては、以下の節で説明します。

オプション 1 : 文字列置換によってコンフィグレーション ファイルを変更する

文字列置換スクリプトを使用して、config.xml ファイルや他のドメインファイルで、アクティビティの検索や置換を実行できます。たとえば、フィルタと一緒に Ant Copy タスクを使用して、文字列置換を実行できます。config.xml のコピーを作成して (たとえば、それを config-subst.xml という名前に変える)、ハードコード化されたパスを変数に置き換えて、そのコピーをチェックインできます。次に、各開発者は、変数と一緒にそのコピーをチェックアウトして、文字列置換スクリプトを実行できます。

文字列置換スクリプトは、マシンに複数の BEA ホーム ディレクトリを設定する以外にも、多くの目的に使用でき、各開発者が、共通のデータ ソース コンフィグレーションを共有する個別のデータベース インスタンスで作業できる方法を提供します。

オプション 2 : BEA ホーム用に共通の仮想ドライブを使用する (Windows)

このオプションを使って、チームの開発者はそれぞれ、自分のマシンで、共通の仮想ドライブ文字をコンフィグレーションします。このドライブは、実際の BEA ホーム ディレクトリの代わりに使用され、任意の開発者が必要な場所に配置できます。「表 2-1 パスがハードコード化されているドメイン ファイル」に示されているコンフィグレーション ファイルと開始スクリプトは、BEA ホーム ディレクトリの代わりに仮想ドライブを使用するように編集でき、これらのファイルはすべてのチーム メンバー間で共有できるようになります。

たとえば、BEA ホーム ディレクトリが現在 D:\BEA-HOME である場合、BEA ホーム ディレクトリにマップするために代替のドライブ文字を作成する一般的な手順は、次のとおりです。

このオプションの欠点 :

オプション 3 : 相対パスを使用する

各開発者のマシンでドメインとアプリケーション ディレクトリが BEA ホーム ディレクトリへの共通の相対パスに配置される場合、config.xml 内のすべてのファイル パスと開始スクリプトを相対パスに変更できます。

ドメインが D:\myBeaHome\user_projects\mydomain にインストールされ、BEA ホーム ディレクトリは D:\myBeaHome であると仮定すると、コード リスト 2-5 に示されているサンプルの config.xml エントリが、太字で強調表示された変更があるコード リスト 2-6 のようになります。

<library>
    <name>p13n-app-lib#9.2.0@9.2.0</name>
    <target>AdminServer</target>
<source-path>../../weblogic92/common/deployable-libraries/p13n-app-lib.ear
</source-path>
    <deployment-order>1</deployment-order>
    <security-dd-model>DDOnly</security-dd-model>
  </library>

もちろん、前のオプションと同様に、「表 2-1 パスがハードコード化されているドメイン ファイル」に一覧表示されているすべてのファイルが同じように変更される必要があります。

このオプションの欠点 :

ポータル ドメインの作成と共有

この節では、チーム メンバーの間でポータル ドメインを共有するための方法を説明します。この方法は、「共有 WebLogic Portal ドメインの作成」で説明した推奨されている方法に代わるものです。

ドメインに対する共通のディレクトリの計画

ドメイン用のソース コントロール システムで、共通のドメイン ルート ディレクトリ (%DOMAINNAME) を作成します。

ドメインの作成

WebLogic Configuration Wizard またはスクリプトを使用してドメインを作成します。Configuration Wizard の使用の詳細については、WebLogic Server ドキュメントの「コンフィグレーション ウィザードを使用した WebLogic ドメインの作成」を参照してください。スクリプトを使用してプログラムでドメインを作成する方法の詳細については、WebLogic Server ドキュメントの「WLST オフラインを使用した WebLogic ドメインの作成とコンフィグレーション」を参照してください。ドメインと共にインストールされるファイルの概要については、WebLogic Server ドキュメントの「ドメイン コンフィグレーション ファイル」を参照してください。

ソース コントロールへのドメインのチェックイン

ドメインを作成した後で、サーバを起動する前に、ドメインをソース コントロールにチェック インします。WebLogic Server の起動時に、多数の一時ファイルおよびディレクトリがドメイン ディレクトリ内に作成されますが、これらのファイルやディレクトリは、ほとんどの場合、ソース コントロール内に存在することが好ましくないものです。表 2-2 は、サーバ起動後に作成されるファイル、およびソース コントロールから除外するファイルを一覧表示しています。

サーバの起動

ドメインの DOMAIN_ROOT/bin/startWeblogic コマンドを使用して WebLogic Server を起動します。ドメインのルート ディレクトリでこのコマンドを見つけることができます。

ドメインのコンフィグレーションと調整

「ドメインのコンフィグレーションと調整」を参照してください。