![]() ![]() ![]() ![]() |
この章では、WebLogic Portal 開発に対する共通の環境をコンフィグレーションおよび管理する方法について説明します。共通の開発環境により、開発者は同じ WebLogic Portal ドメイン、データベース、アプリケーション コンフィグレーションを共有し、ソース コントロール システムでのこれらの要素を保持することができます。きちんと計画されたチーム開発により、WebLogic Portal アプリケーションの開発、ビルド、および更新をすばやく、一貫性のある方法で行うことができます。
WebLogic Portal のチーム開発環境のコンフィグレーションに必要な基本のタスクには、次のものがあります。
WebLogic Portal Web サイトのチーム開発は、適切なソース コントロールを中心として行われます。ソース コントロール システムを正しく利用すれば、チーム メンバーが 1 つになること、開発チームの規模をすばやく拡大できること、データ損失の防止などの、多数の利点がもたらされます。
ソース コントロールのプロバイダには、CVS、Subversion (SVN)、Perforce、StarTeam、Visual Source Safe (VSS)、PVCS などの、さまざまなものがあります。この章は、このようなベンダのうちどれを使用する場合にも役立ちます。ただし、コードの格納に関しては、ベンダはそれぞれ異なる特徴を持っています。ポータル アプリケーションをチーム開発するためのソース コントロール管理システムを選択するときに考慮すべき重要な事項の一つに、ファイルの自由なチェック アウト モデルのサポートがあります。なぜなら、ドメインとアプリケーションのファイルの多くは、ソース コントロール管理へのチェック インが必要であり、またサーバによる書き込みが可能でなければならないからです。自由なチェックアウト モデルとは、複数のユーザがチェックアウトでき、同時にファイルを編集できることを意味します。すなわち、個々のユーザは、ファイルをチェックアウトするとき、他のユーザに対してファイルを「ロック」しません。
ヒント : | Workshop for WebLogic の Eclipse ベースの統合されたソース コントロール機能を使用したプロジェクト ファイルの共有については、Workshop for WebLogic のドキュメントの「ソース コントロールの操作」を参照してください。 |
この節では、共有 WebLogic Portal ドメイン作成の基本的手順、および次のトピックについて説明します。
WebLogic Portal ドメインは、ポータルを構築する基盤です。ドメインには、サーバ環境を定義し実行するコンフィグレーション ファイル、データベース、およびスクリプトが含まれ、デフォルトのセキュリティ レルムと事前に定義されたシステム管理者を提供し、サーバ管理ツールを提供します。ドメインには、ポータルと関連機能を構築するためのファイルとサービスも含まれます。
基本的なドメイン インフラストラクチャは、1 つの管理サーバとオプションの管理対象サーバおよびクラスタで構成されます。これらのコンポーネントの詳細、およびドメインの詳しい説明については、WebLogic Server ドキュメントの『コンフィグレーション ウィザードを使用した WebLogic ドメインの作成』を参照してください。
チーム開発環境では、ドメイン関連ファイルがソース コントロールに保存され、個々の開発マシンにチェックアウトされます。チーム メンバーは、ソース コントロールを使用してこれらのドメイン ファイルを共有します。これによって、既存のデプロイ済みアプリケーションに対するすべての変更内容、新規アプリケーションの追加、およびコンフィグレーション ファイルに格納されているその他の設定やスクリプトを共有できるようになります。
ヒント : | ドメインを作成して開発チームのメンバーに配布するには、ドメイン ファイル自体でなく、ドメイン テンプレートを使用することをお勧めします。これらのテンプレートをソース コントロールにチェックインします。ドメイン テンプレートの作成については、「WebLogic Portal ドメイン テンプレートの作成」を参照してください。 |
チームのすべての開発者は、最初に、開発マシンに WebLogic Portal をインストールする必要があります。必須ではありませんが、すべての開発者が、共有のホーム ディレクトリに WebLogic Portal をインストールすることをお勧めします。
チーム メンバーに共通のコンフィグレーション ドメインを配布する方法としては、ドメイン テンプレートを作成し、それをソース コントロールにチェックインすることをお勧めします。
ヒント : | チームのメンバーがデフォルトの WebLogic Portal ドメインのみを必要とする場合は、個々のマシンで WebLogic Configuration Wizard を使用してデフォルトの WebLogic Portal ドメインを簡単に作成できます。この場合、ソース コントロールにチェックインする必要があるドメイン ファイルはありません。一方、JDBC、JMS、または追加の共有ライブラリのような特別なドメイン コンフィグレーションが必要な場合は、カスタム ドメイン テンプレートをお勧めします。Configuration Wizard の使用の詳細については、WebLogic Server ドキュメントの『コンフィグレーション ウィザードを使用した WebLogic コンフィグレーションの作成』を参照してください。 |
ドメイン テンプレートは、新しいドメインを作成するのに使用されます。ドメイン テンプレートは、インフラストラクチャ コンポーネント、アプリケーション、サービス、セキュリティ オプション、一般環境とオペレーティング システム パラメータなど、ドメイン内のリソースの完全なセットを定義します。既存のテンプレートまたは既存のドメインから、ドメイン テンプレートを作成できます。共有ドメイン テンプレートを指定すると、チーム内の全開発者は、個々の開発マシンで同じドメイン コンフィグレーションを効率的に作成できます。
ドメイン テンプレートの作成の詳細については、WebLogic Server ドキュメントの「WebLogic Configuration Template Builder によるコンフィグレーション テンプレートの作成」を参照してください。
ドメイン テンプレートが作成されて、ソース コントロールにチェックインされると、各開発者は、テンプレートをチェックアウトして、自分独自のローカル ドメインを作成できます。開発者が同じテンプレートを使用してドメインを作成できるので、ドメインのコンテンツは同等になります。
各開発者はドメイン テンプレートを使用し、WebLogic Configuration Wizard またはスクリプトを使ってローカル ドメインを作成します。Configuration Wizard の使用の詳細については、WebLogic Server ドキュメントの『コンフィグレーション ウィザードを使用した WebLogic ドメインの作成』を参照してください。ドメインと共にインストールされるファイルの概要については、WebLogic Server ドキュメントの「ドメイン コンフィグレーション ファイル」を参照してください。
ヒント : | スクリプトを使用してプログラムでドメインを作成する方法の詳細については、WebLogic Server ドキュメントの「WLST オフラインを使用した WebLogic ドメインの作成とコンフィグレーション」を参照してください。 |
ヒント : | 開発における一般的なアクティビティの 1 つに、システムのテストに使用する基本的なユーザ セットの作成があります。「ユーザ、グループ、ロール、および資格の更新」も参照してください。 |
ドメインの 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 などのエンタープライズ品質データベースを使用して、各開発者が自分専用のポータル データベースを使用して作業することが一般的です。
注意 : | Oracle と DB2 では、開発データベースについては、開発者ごとに別のデータベース スキーマを使用することをお勧めします。Sybase と SQL Server では、開発データベース インスタンスについては、開発者ごとに別のデータベースとデータベース ログ ファイルを使用することをお勧めします。MySQL については、開発者ごとに別のデータベースを使用することをお勧めします。 |
各開発ドメインは、ドメイン テンプレートを通じて、DOMAIN_HOME/config/jdbc
ディレクトリの複数の XML ファイルに一覧表示されている特定のデータベースを使用するようにコンフィグレーションされます。詳細については、「WebLogic Portal のデータベース管理ガイド」を参照してください。
一般に、ステージングとプロダクションで使用する予定のエンタープライズ品質の DBMS と同じものを、開発でも使用することをお勧めします。たとえば、Oracle でアプリケーションをデプロイする予定の場合には、アプリケーションも Oracle で開発することをお勧めします。この方法により、パフォーマンスが向上し、データのベースラインの保守が簡単になります (データベース管理者の適切なサポートとスクリプトが必要)。
開発であるタイプのデータベースを使用し、ステージングとプロダクションに別のデータベースを使用し、伝播ツールを使ってそれらのデータベース間でデータを移動することも可能です。この場合、開発者は、開発で PointBase を使用し、ステージングとプロダクション システムでは Oracle のようなエンタープライズ品質データベースを使用できます。伝播ツールを使用して、開発システムからデータベース インベントリをエクスポートして、それをステージングまたはプロダクション システムにインポートできます。伝播ツールの使用の詳細については、「Workshop for WebLogic 伝播ツールの使用」を参照してください。
一般に、WebLogic Portal Administration Console を使用して行うアクティビティのほとんどは、データベースに永続的に保存されますが、資格は組み込み LDAP に永続的に保存されます。ただし、テスト ユーザを、テスト ユーザに割り当てられているユーザ プロパティと一緒に使用して開発する場合もあります。
このようなプロパティはデータベースに格納されます。さらに、サービス管理コンフィグレーションはデータベースではなく、アプリケーションのデプロイメント計画に保持されます。BEA リポジトリに格納されている実際のコンテンツはデータベース内にありますが、コンテンツ リポジトリのコンフィグレーションはデータベースには保持されません (ファイル システム リポジトリを使用している場合、コンテンツ メタデータのみがデータベースに格納されます)。
資格の詳細については、「WebLogic Portal のセキュリティ ガイド」を参照してください。
PointBase に対する開発ライセンスは、WebLogic Portal でインストールされます。開発ライセンスでは、データベース サイズは 30MB に制限されています。この制限を増やすには、フル ライセンスを購入する必要があります。また、PointBase はデータベースを使用するにつれて増大するバイナリ ファイルにデータを格納します。チーム環境でバイナリ ファイルを処理することについては、「ソース コントロールでのバイナリ ファイルの管理」を参照してください。
PointBase データベース サーバが自動的に起動および停止しないようにするには、ドメインの POINTBASE_FLAG
を false
(デフォルトは true
) に設定します。そのためには、次の手順を行います。
Windows システムの DOMAIN_HOME/bin/setDomainEnv.cmd
ファイルで、以下を入力します。
UNIX システムの DOMAIN_HOME/bin/setDomainEnv.sh
ファイルで、以下を入力します。
nopointbase
オプションと共に startWebLogic
コマンドを実行しても、同じ結果を得ることができます。
デフォルト ドメイン テンプレートを使って WebLogic Portal ドメインを作成すると、samplesDataSource というデータソースが自動的にドメインに含まれます。このデータソースは、必要に応じてドメインから削除することができます。データソースを削除するには、WebLogic Server Administration Console を使用してください。Administration Console のメイン ページから、[JDBC|データ ソース] を選択してください。[ロックして編集] をクリックして、テーブルから [samplesDataSource] を選択し、[削除]をクリックします。
サンプルの PointBase データベースもデフォルトの WebLogic Portal ドメインでインストールされます。通常、このデータベースは例およびテストの目的でのみ使用します。ドメインのすべてのデータソースが非 PointBase データベースを指す場合、アプリケーションをプロダクション サーバにデプロイする前に、このデータベースを削除することをお勧めします。データベースを削除するには、以下のファイルをドメインから単に削除してください。
ポータル ドメインをコンフィグレーションしたら、開発チームのすべてのメンバーにより共有される新しいポータル アプリケーションを作成する必要があります。
ヒント : | チーム メンバー内でポータル アプリケーション コードの共有を計画するには、WebLogic Portal アプリケーションで共有 J2EE ライブラリのロールを理解することが重要です。この重要なトピックの詳細については、WebLogic Server ドキュメントの「共有 J2EE ライブラリおよびオプション パッケージの作成」を参照してください。共有ライブラリについては、「WebLogic ポータル開発ガイド」と「J2EE 共有ライブラリのデプロイ」も参照してください。 |
ドメイン作成のように、アプリケーション作成にはいくつかの手順があります。これらの手順はこの節で説明されています。以下のものが含まれます。
Workshop for WebLogic で作成したすべてのプロジェクトは、ワークスペース ディレクトリ内に作成されます。ワークスペースとプロジェクトの作成の詳細については、「WebLogic ポータル開発ガイド」を参照してください。
Workshop for WebLogic を使用して、1 つまたは複数のポータル EAR プロジェクトを作成します。EAR プロジェクトは主に Web アプリケーションと J2EE 共有ライブラリを参照するコンフィグレーション ファイルで構成されています。
EAR プロジェクトを作成するとき、図 2-1 に示すように、WebLogic Portal ファセットのセットなど、プロジェクトに含めるプロジェクト ファセットを選択します。
ファセットは特定の機能に対して必要とされる J2EE 共有ライブラリと IDE 機能のセットをグループ化するのに便利な方法です。たとえば、Admin Console ファセットは、WebLogic Portal Administration Console をデプロイし実行するのに必要な J2EE 共有ライブラリをグループ化します。ファセットを含めない場合は、それを選択解除できます。一部のファセットは他のファセットに依存します。依存関係があるファセットを削除しようとすると、ダイアログ ボックスが警告を表示し、その特定の変更を禁止します。
ヒント : | 開発目的のため、ポータル EAR プロジェクトを作成するとき、WebLogic Portal ファセットのすべてを選択することをお勧めします。ポータルをプロダクション環境に移動する前に、一部のファセットを選択的に削除できます。たとえば、プロダクション環境にデプロイする前に、WebLogic Portal Administration Console を削除できます。ファセットの追加および削除に関する詳細については、『WebLogic ポータル開発ガイド』を参照してください。「チーム環境での J2EE 共有ライブラリの使用」も参照してください。 |
ポータル EAR プロジェクトの作成の詳細については、『WebLogic ポータル開発ガイド』を参照してください。
Workshop for WebLogic を使用して、ポータル Web プロジェクトを作成します。ポータル Web プロジェクトには、ポータルのソース コードと、プロジェクトにより使用される J2EE 共有ライブラリを参照するコンフィグレーション ファイルが含まれます。
Web プロジェクトを作成するとき、図 2-2 に示すように、WebLogic Portal ファセットなど、プロジェクトに含めるプロジェクト ファセットを選択します。
ヒント : | 開発目的のため、ポータル Web プロジェクトを作成するときに WebLogic Portal ファセットのすべてを選択することをお勧めします。ポータルをプロダクション環境に移動するとき、一部のファセット コンポーネント (機能) を選択的に削除できます。詳細については、「チーム環境での J2EE 共有ライブラリの使用」を参照してください。 |
書き込むアプリケーション コードは、Web プロジェクト内のファイルに保存されます。一般的なアプリケーションでは、コードは Web プロジェクトの WebContent
ディレクトリに配置されます。BEA により供給されるドメインとアプリケーション特定コードは、J2EE 共有ライブラリに格納され、アプリケーションにより参照されます。
ポータル Web プロジェクトの作成の詳細については、『WebLogic ポータル開発ガイド』を参照してください。
書き込むコードは、BEA が J2EE 共有ライブラリに提供するドメインとアプリケーション コードから、物理的に分離されます。必要なのは、自分または自分のチームのメンバーが書き込んだアプリケーションコードをソース コントロール システムに格納することだけです。デフォルトでは、アプリケーション コードは Web アプリケーションの WebContent
ディレクトリに配置されます。Java ソース コードは、src
ディレクトリに配置されます。Eclipse は、プロジェクト設定およびプロジェクト内のその他のコンフィグレーションも格納します。ファイルには以下のものが含まれます。
新しいコンポーネントが作成されるので、これらの新しいコンポーネントの多くは、ソース コントロールにチェックインする必要があります。開発者は、作成されているファイルのうちどれが、ソース コントロールで共有する必要があるのかを知る必要があります。
ソース コントロールから、Web プロジェクトに固有の Java 出力ディレクトリを除外します。一般に、これらのディレクトリには、build
または bin
と名前が付いています。また、ハードコード化されたパスを含むファイルのチェックインは避けます。
ヒント : | ソース コントロールから除外するファイルおよびポータブル ワークスペース ZIP ファイルの作成の詳細については、Workshop for WebLogic ドキュメントの「ソース コントロールの操作」を参照してください。 |
デプロイメント中に共通で更新されて、ソース コントロールにチェックインする必要がある 3 つのファイルには、次が含まれます。これらのファイルは、エンタープライズ アプリケーションの META-INF
ディレクトリに配置されます。
ヒント : | J2EE 共有ライブラリの内部にあるファイルを変更する場合、自分のファイル システムにそれをコピーして変更できます。その時点から、ファイル ベースのコピーが J2EE 共有ライブラリに保存されているバージョンよりも優先します。開発環境では、コピーした J2EE 共有ライブラリ ファイルをソース コントロールにチェックインする場合、他の開発者がそれらを共有できることに注意してください。すべてのファイルを共有ライブラリからコピーできるわけではありません。たとえば、.class や .jar ファイルはコピーすることができません。 |
ソース コントロール管理と 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 にインポートする必要があります。これを実行するには、[ファイル|インポート] を選択します。[インポート] ダイアログで、[既存プロジェクトをワークスペースへ] を選択します。次に、オンライン ヘルプの指示に従い、プロジェクトの位置を突き止めてインポートします。
ヒント : | Eclipse での共有プロジェクトの追加情報については、Eclipse のドキュメントを参照してください。 |
J2EE 共有ライブラリは、J2EE アプリケーションまたは Web アプリケーションの再利用可能部分です。エンタープライズ アプリケーション レベルでは、J2EE 共有ライブラリは、Java クラス、EJB デプロイメント、および Web アプリケーションを含むことができる EAR ファイルです。Web アプリケーション レベルでは、J2EE 共有ライブラリは、サーブレット、JSP、タグ ライブラリを含むことができる WAR ファイルです。標準 EAR または WAR ファイルと、J2EE 共有ライブラリ間の違いは、参照によって複数の共有ライブラリを 1 つのアプリケーションに含むことができることと、複数のアプリケーションが単一の J2EE 共有ライブラリを参照できることです。
WebLogic Portal 開発チームの共有ライブラリの最も有効な側面の 1 つは、チームによって開発されるコードと BEA により配布されるコードが物理的に分離されたままであるということです。WebLogic Portal の更新またはパッチが共有ライブラリとして配布されるとき、実行する必要があるのは、インストール ディレクトリに新しいライブラリを追加することだけです。参照するアプリケーションと、開発者によって書き込まれるコードは、アプリケーションが再デプロイされるときに自動的に新しいモジュールをピックアップします。
ヒント : | J2EE 共有ライブラリの詳細については、WebLogic Server ドキュメントの「共有 J2EE ライブラリおよびオプション パッケージの作成」および『WebLogic ポータル開発ガイド』を参照してください。 |
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
ファイルが含まれており、それにはライブラリ名とバージョン情報が含まれています。共有ライブラリがデプロイされたら、このマニフェストを通じて、サーバがそれを識別し、デプロイされているアプリケーションにそれをアセンブルすることができます。
ヒント : | マニフェスト ファイルに関する詳細については、「共有ライブラリのマニフェスト ファイルの目次」を参照してください。共有ライブラリのデプロイの詳細については、「J2EE 共有ライブラリのデプロイ」を参照してください。 |
コード リスト 2-4 は、ライブラリ内のデプロイメント記述子がすべて読み込まれて解釈された後の、最終的にデプロイされるアプリケーションの効率的なコンフィグレーションを示しています。サーバは 2 つの EJB JAR ファイルをデプロイします。myEjb.jar
ファイルは myApp.ear
アーカイブから、別の libEjb.jar
は J2EE 共有ライブラリから取得します。さらに、myApp
の myClasses.jar
内のクラスが、AppLibOne
J2EE 共有ライブラリ内の code.jar
ファイルからのクラスをオーバーライドするように、アプリケーションのクラスパスが順序付けされます。
アーカイブのMETA-INF/MANIFEST.MF
ファイルを作成または変更することによって、 WAR または EAR などの J2EE モジュールを有効化して J2EE 共有ライブラリとすることができます。この節では、J2EE 共有ライブラリのマニフェスト ファイルに入れる変数を説明します。
サンプルの MANIFEST.MF
ファイルを以下に示します。
META-INF/MANIFEST.MF
Extension-Name: SomePortlets
Specification-Version: 1.0
Implementation-Version: 1.0
表 2-1 では、ファイルの内容について説明します。
ヒント : | MANIFEST.MF ファイルの作成に関する詳細については、WebLogic Server ドキュメントの「共有 J2EE ライブラリの作成」を参照してください。 |
表 2-1 に示すMANIFEST.MF
変数に加えて、以下の変数を使用して [プロジェクトにコピー]機能から明示的に特定のファイルを追加または除外することもできます。この機能を使用して、特定のファイルを直接共有ライブラリからユーザのプロジェクト ワークスペースにコピーすることができます。[プロジェクトにコピー] からファイルを明示的に追加または削除するには、以下の変数を使用します。
追加も削除も指定しないと、ライブラリにあるコピー可能なすべてのファイルがコピーされます。追加と削除の両方を指定すると、まず追加対象ファイルの正規表現と一致するすべてのファイルを検出し、次に追加ファイルのリストから削除対象ファイルが削除されます。
BEA-EXTRACT-INCLUDE/EXCLUDE
のフォーマットは正規表現 (javax.util.regex.Pattern から) であり、削除または追加する対象を指定します。たとえば、ライブラリのディレクトリ構造が コード リスト 2-5 に示すディレクトリ構造と同じであるとします。
/WEB-INF/web.xml
/WEB-INF/classes/log4j.properties
/includes/test.jsp
/includes/bob.jsp
/css/some.css
BEA-EXTRACT-INCLUDE: (/WEB-INF/[_0-9a-zA-Z ]*)|(css)
/WEB-INF/
と一致するすべてのファイル、および文字 (文字数は無制限) を抽出します。
文字には「_」、0 ~ 9、a ~ z、A ~ Z が含まれます。または、 /css/
を含むすべてのファイルが抽出されます。この場合は、以下のファイルは、[プロジェクトにコピー] の操作中に抽出されます。
/WEB-INF/web.xml
/WEB-INF/classes/log4j.properties
/css/some.css
正規表現はファイルの絶対パスに一致しないため、上の例では /css/
は「css」が含まれるパスにあるすべてのファイルに一致します。したがって、これらの例のディレクトリやファイルも、正規表現と一致します。
/adirectory1/css/bob.joe
/main.css
ファイルの絶対パスに一致させたい場合は、^
や $
のような正規表現の文字を使用します。(^/hiddenFolder/.*$
など。)
コード リスト 2-6 では、両方の変数を含むマニフェストを示します。
Extension-Name: p13n-app-lib
Specification-Version: 10.0.0
Implementation-Version: 10.0.0
BEA-EXTRACT-INCLUDE: (/META-INF/p13n-config.xml)|(css)
BEA-EXTRACT-EXCLUDE: xml
共有ライブラリは、開発チームが開発したポータル リソースを他のチームと共有するのに便利なメカニズムを提供します。
たとえば、あるチームの環境が、1 つまたは複数のポートレット開発チームと、ポータル全体のアセンブルとメンテナンスを担当するチームで構成されているとします。図 2-3 にサンプル シナリオを示します。ポータル開発チームは、共有ライブラリ (WAR) ファイルを、ポートレット開発チームに配布します。ライブラリ ファイルには、ポータルと、ポータル ルック アンド フィールのような関連リソースが含まれます。ポートレット チームは、このファイルを受け取ってそれを共有ライブラリとしてプロジェクト スペースにインポートし、それをチーム メンバーが利用できるようにして、ポートレットをテストするためのポータルを提供します。
ポートレット チームはポートレットのセットを構築後、共有ライブラリ (WAR) ファイルをポータル チームに戻します。ポータル チームは WAR を受け取り、それをモジュールとしてインポートし、ポートレットをポータルに追加します。J2EE 共有ライブラリの作成の詳細については、WebLogic Server ドキュメントの J2EE ライブラリおよびオプション パッケージの作成に関する説明を参照してください。
共有ライブラリとしてリソースを共有するのに含まれる基本の手順には、次が含まれます。
MANIFEST/MANIFEST.MF
ファイルに追加して、WAR を J2EE 共有ライブラリとして有効にします。WAR を J2EE 共有ライブラリとして有効にすることについては、「チーム環境での J2EE 共有ライブラリの使用」を参照してください。次に例を示します。META-INF/MANIFEST.MF
Extension-Name: SomePortlets
Specification-Version: 1.0
Implementation-Version: 1.0
ヒント : | 一貫性のあるサブディレクトリ名を含むポートレット開発用の命名規約を選択します。一貫性のある命名規約は、ソース ファイルをパッケージ化し配布するプロセスを単純化します。 |
共有ライブラリ WAR ファイルを受け取ると、ポータル チームは適切なコンフィグレーション ファイル内の共有ライブラリ WAR ファイル (および、オプションで、そのバージョン番号) を参照します。共有ライブラリ WAR ファイルへの参照は、ポータル Web アプリケーションの weblogic.xml
ファイルおよびドメインの config.xml
ファイルに移動します。
weblogic.xml
ファイルにはライブラリ名 (およびオプションでバージョン番号) が含まれ、ドメインの config.xml
ファイルには共有ライブラリ WAR ファイルの実際のパスが含まれます。J2EE 共有ライブラリの参照については、「チーム環境での J2EE 共有ライブラリの使用」を参照してください。
ヒント : | 開発段階を始める前に、ポートレット チームはポータル チームから、ポートレットと一緒に使用するルック アンド フィール ファイル、ライブラリ、およびメニューのセットを受け取る場合があります。このようなリソースが J2EE 共有ライブラリ ファイルでポートレット チームに配布される場合は、ポートレット チームはこの節で説明されているのと同じ手順に従って、それを単に受け取って、インストールできます。この場合、ポートレット チームには、共有ライブラリ WAR ファイルから削除する項目は少なくなる可能性があります。 |
次のように、プロジェクトの Java ビルド パスにライブラリを追加する必要があります。
ポートレットをデプロイされたポータルに組み込むため、ポータル チームは WebLogic Server Console を使用して、WAR ファイルを J2EE 共有ライブラリとしてデプロイします。
この節では、チーム開発環境でのポータル アプリケーション ソース コードの管理について説明します。
ヒント : | Workshop for WebLogic の Eclipse ベースの統合されたソース コントロール機能を使用したプロジェクト ファイルの共有については、Workshop for WebLogic のドキュメントの「ソース コントロールの操作」を参照してください。 |
多数の汎用 Java ライブラリをポータルで使用する場合は、Java ライブラリを、ポータル エンタープライズ アーカイブ内の Java プロジェクトに格納するか、または J2EE 共有ライブラリとしてパッケージ化することをお勧めします。このようにすれば、サーバの複数のインスタンスに Java ライブラリを移植することが可能になり、ライブラリを再利用および共有するためのパッケージ化も容易になります。
ベスト プラクティスは、エンタープライズ アプリケーションの APP-INF/lib
ディレクトリに Java ライブラリを含む JAR ファイルを配置するか、J2EE 共有ライブラリとして JAR ファイルをコンフィグレーションすることです。J2EE 共有ライブラリの作成の詳細については、WebLogic Server ドキュメントの J2EE ライブラリおよびオプション パッケージの作成に関する説明を参照してください。
クロスプラットフォーム環境での開発とデプロイにおけるコーディングでは、以下のベスト プラクティスに従ってください。
myPortletContent.jsp
というファイルを作成し、Windows 上でコンテンツ URI としてファイル MyPortletContent.jsp
を指定しても問題ありません。ただし、この同じアプリケーションを UNIX 上にデプロイすると、ファイル MyPortletContent.jsp
が見つからないというエラーが発生します。
定義ラベルと呼ばれる一意の識別子は、Workshop for WebLogic でポータルに追加する各ブック、ページ、およびポートレットに対して自動的に生成されます。プロパティ ビューで Workshop for WebLogic のコンポーネントに対する定義ラベルを表示できます。
複数の開発者が新しいポータル コンポーネントを作成していると、異なるコンポーネントに対して同一の定義ラベルが自動的に生成される場合があります。定義ラベルの重複を避けるには、命名規約を使用して新しいコンポーネントごとに手動で定義ラベルを変更します。
定義ラベルの変更については、『ポータル開発ガイド』を参照してください。
警告 : | 伝播ツールを使用して環境間で変更を伝播した後は、ポートレット、ページ、およびブックに対する定義ラベルを変更しないことが非常に重要です。伝播ツールは、定義ラベルとインスタンス ラベルを使用して、ソースと宛先システム間の違いを識別します。ポータル伝播後にこれらのラベルに変更すると、矛盾が生じるおそれがあります。 |
作成したコードは、クラスタ環境において十分にテストしてください。また、セッション データが管理可能なサイズを超えないように維持し、クラスタ全体でのセッション共有をサポートするように Web アプリケーションをコンフィグレーションします。セッション データがシリアライズ可能であることを確認します。クラスタ化情報については、「ポータル クラスタのコンフィグレーション」を参照してください。
ヒント : | WebLogic Server は HTTP セッション問題をデバッグするのに有効なセッション監視ツールを提供します。詳細については、WebLogic Server ドキュメントの「クラス SessionMonitor」を参照してください。 |
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-4 ソース コントロールから除外するドメイン ファイル」を参照)。
プロジェクト開発の進行中に、既存のユーザ、グループ、ロール、および資格が変更されることもあります。ユーザ、グループ、ロール、および資格を WebLogic Portal Administration Console を使ってコンフィグレーションできます。データベースと LDAP 変更をソース コントロールに保持することが重要です。
資格の詳細については、「WebLogic Portal のセキュリティ ガイド」を参照してください。ユーザとグループの詳細については、「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 ドメインの作成」で説明した、ポータル ドメインを作成し、チームメンバー間で共有するという推奨されている方法では十分でない場合の代替の方法を説明します。
任意のシステムで WebLogic Platform ソフトウェアがインストールされるディレクトリを、BEA ホーム ディレクトリと呼びます。図 2-4 にホーム ディレクトリの例を示します。チーム環境にある各開発マシンには、固有の BEA ホーム ディレクトリがあります。
Workshop for WebLogic アプリケーションとドメインはそれぞれ BEA ホーム ディレクトリを参照するので、BEA ホーム ディレクトリをどこに配置するかを注意深く検討することが重要です。最も単純なコンフィグレーションは、チーム環境のすべてのマシンがまったく同じ BEA ホーム ディレクトリ (同じドライブ/ディレクトリ名) を使用する場合です。これ以外の場合は、異なる BEA ホーム ディレクトリの場所を管理するための方針を選択する必要があります。これらの方針については、この節で説明されています。
ドメインの Configuration Wizard を使用して新しいポータル ドメインを作成するときに、そのドメインでどの BEA ホーム ディレクトリを参照するかを選択します。このディレクトリに対する物理的なパスは、各開発マシンのポータル ドメインの config/config.xml
ファイル、startWeblogic.cmd
のようなドメイン バッチ スクリプト、およびその他のドメインファイルに含まれます (完全なリストについては、表 2-3 を参照)。
たとえば、コード リスト 2-7 は、config.xml
ファイルの一部を示しています。この例では、<source-path>
要素は、D:\myBeaHome
のサブディレクトリにある J2EE 共有ライブラリ ファイルを指し示しています。この場合 D:\myBeaHome
が BEA ホーム ディレクトリです。
<library>
<name>p13n-app-lib#10.0.0@10.0.0</name>
<target>AdminServer</target>
<source-path>D:\myBeaHome\wlserver_10.0\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-3 は、ハードコード化された BEA ホーム ディレクトリ パスを含むドメインにあるファイルのすべてを一覧表示します。表 2-3 に表示されているファイルは、ドメインのルート ディレクトリを基準にしています。
次の節では、チーム メンバー全員が同じ BEA ホーム ディレクトリを使用することが不可能な場合の方法を説明します。
チーム メンバー全員が同じ BEA ホーム ディレクトリを使用できる場合は、「ポータル ドメインの作成と共有」に進んでかまいません。
コンテンツが同等のドメインを、チームメンバーと、別の BEA ホーム ディレクトリを使って共有するためのさなざまな方法があります。これらのオプションについては、以下の節で説明します。
文字列置換スクリプトを使用して、config.xml
ファイルや他のドメインファイルで、アクティビティの検索や置換を実行できます。たとえば、フィルタと一緒に Ant Copy タスクを使用して、文字列置換を実行できます。config.xml
のコピーを作成して (たとえば、それを config-subst.xml
という名前に変える)、ハードコード化されたパスを変数に置き換えて、そのコピーをチェックインできます。次に、各開発者は、変数と一緒にそのコピーをチェックアウトして、文字列置換スクリプトを実行できます。
文字列置換スクリプトは、マシンに複数の BEA ホーム ディレクトリを設定する以外にも、多くの目的に使用でき、各開発者が、共通のデータ ソース コンフィグレーションを共有する個別のデータベース インスタンスで作業できる方法を提供します。
このオプションを使って、チームの開発者はそれぞれ、自分のマシンで、共通の仮想ドライブ文字をコンフィグレーションします。このドライブは、実際の BEA ホーム ディレクトリの代わりに使用され、任意の開発者が必要な場所に配置できます。「表 2-3 パスがハードコード化されているドメイン ファイル」に示されているコンフィグレーション ファイルと開始スクリプトは、BEA ホーム ディレクトリの代わりに仮想ドライブを使用するように編集でき、これらのファイルはすべてのチーム メンバー間で共有できるようになります。
たとえば、BEA ホーム ディレクトリが現在 D:\BEA-HOME
である場合、BEA ホーム ディレクトリにマップするために代替のドライブ文字を作成する一般的な手順は、次のとおりです。
ヒント : | 別の開発者が WebLogic Server を別の場所、たとえば D:\bea にインストールする場合、subst P: d:\bea のような類似した置換を実行し、同じ config.xml と開始スクリプトを共有できます。 |
subst
コマンドを実行しなければならない。ただし、このコマンドをテキスト ファイル内に入力し、そのファイルに .cmd
という拡張子を付けて保存し、プログラムの /Startup
フォルダに置くことによって、システム起動時に自動的にコマンドが実行されます。ln
コマンドを使って、シンボリック リンクを使った同様の方法を使用できます。
各開発者のマシンでドメインとアプリケーション ディレクトリが BEA ホーム ディレクトリへの共通の相対パスに配置される場合、config.xml
内のすべてのファイル パスと開始スクリプトを相対パスに変更できます。
ドメインが D:\myBeaHome\user_projects\mydomain
にインストールされ、BEA ホーム ディレクトリは D:\myBeaHome
であると仮定すると、コード リスト 2-7 に示されているサンプルの config.xml
エントリが、太字で強調表示された変更があるコード リスト 2-8 のようになります。
<library>
<name>p13n-app-lib#10.0.0@10.0.0</name>
<target>AdminServer</target>
<source-path>../../wlserver_10.0/common/deployable-libraries/p13n-app-lib.ear
</source-path>
<deployment-order>1</deployment-order>
<security-dd-model>DDOnly</security-dd-model>
</library>
もちろん、前のオプションと同様に、「表 2-3 パスがハードコード化されているドメイン ファイル」に一覧表示されているすべてのファイルが同じように変更される必要があります。
この節では、チーム メンバーの間でポータル ドメインを共有するための方法を説明します。この方法は、「共有 WebLogic Portal ドメインの作成」で説明した推奨されている方法に代わるものです。
ドメイン用のソース コントロール システムで、共通のドメイン ルート ディレクトリ (%DOMAINNAME
) を作成します。
注意 : | ドメインの作成については、「共有 WebLogic Portal ドメインの作成」で説明されています。アプリケーションの作成については、「ポータル アプリケーションの作成と共有」で詳しく説明されています。 |
WebLogic Configuration Wizard またはスクリプトを使用してドメインを作成します。Configuration Wizard の使用の詳細については、WebLogic Server ドキュメントの『コンフィグレーション ウィザードを使用した WebLogic ドメインの作成』を参照してください。スクリプトを使用してプログラムでドメインを作成する方法の詳細については、WebLogic Server ドキュメントの「WLST オフラインを使用した WebLogic ドメインの作成とコンフィグレーション」を参照してください。ドメインと共にインストールされるファイルの概要については、WebLogic Server ドキュメントの「ドメイン コンフィグレーション ファイル」を参照してください。
ヒント : | Workshop for WebLogic の Eclipse ベースの統合されたソース コントロール機能を使用したプロジェクト ファイルの共有については、Workshop for WebLogic のドキュメントの「ソース コントロールの操作」を参照してください。 |
ドメインを作成した後で、サーバを起動する前に、ドメインをソース コントロールにチェック インします。WebLogic Server の起動時に、多数の一時ファイルおよびディレクトリがドメイン ディレクトリ内に作成されますが、これらのファイルやディレクトリは、ほとんどの場合、ソース コントロール内に存在することが好ましくないものです。表 2-4 に、サーバ起動後に作成されるファイル、およびソース コントロールから除外するファイルを示します。
ドメインの DOMAIN_ROOT/bin/startWeblogic
コマンドを使用して WebLogic Server を起動します。ドメインのルート ディレクトリでこのコマンドを見つけることができます。
「ドメインのコンフィグレーションと調整」を参照してください。
![]() ![]() ![]() |