プロダクション業務ユーザーズ ガイド
|
 |
 |
|
WebLogic Portal Web サイトのチーム開発は、適切なソース コントロールを中心として行われます。ソース コントロール システムを正しく利用すれば、チーム メンバーが一つになることや、開発チームの規模をすばやく拡大できること、およびデータ損失の防止などの、多数の利点がもたらされます。
この節では、ソース コントロールの中で共通の開発ドメイン、データベースのデータ、およびポータル アプリケーションをコンフィグレーション、格納、管理する方法を説明します。これを参考にすれば、ポータル アプリケーションの開発、ビルド、および更新をすばやく、一貫性のある方法で行うことができるようになります。
ソース コントロールのプロバイダには、CVS、Perforce、Starteam、Visual Source Safe (VSS)、およびPVCS などの、さまざまなものがあります。このガイドは、このようなベンダのうちどれを使用する場合にも役立つように作られています。ただし、コードの格納に関しては、ベンダはそれぞれ異なる特徴を持っています。ポータル アプリケーションをチーム開発するためのソース コントロール管理システムを選択するときに考慮すべき重要な事項の一つに、ファイルの自由なチェック アウト モデルのサポートがあります。ドメインとアプリケーションのファイルの多くは、ソース コントロール管理へのチェック インが必要であり、またサーバによる書き込みが可能でなければなりません。
注意 : WebLogic Workshop と直接統合していないソース コントロール管理ツールであっても (Visual Studio Source Control Provider for WebLogic Workshop を参照してください)、そのツールを使用して WebLogic Server のドメインおよびアプリケーションを管理することが可能です。
開発チームのリーダーが、グループの適切なポータル ドメインを作成します。ドメイン資産を作成および格納する前に、BEA ホーム ディレクトリ、つまりチームが WebLogic ソフトウェアをインストールする場所を決定します。
WebLogic Platform ソフトウェアがインストールされるディレクトリを、BEA ホーム ディレクトリと呼びます。WebLogic Workshop アプリケーションおよびドメインは、それぞれ BEA ホーム ディレクトリを参照します。BEA ホーム ディレクトリを配置する場所を慎重に検討することが重要です。WebLogic Platform をインストールするときに、開発者がインストール先のドライブとディレクトリを選択できます。
ドメインの Configuration Wizard を使用して新しいポータル ドメインを作成するときに、そのドメインでどの BEA ホーム ディレクトリを参照するかを選択します。このディレクトリへの物理パスは、各開発マシン上に存在する、ポータル ドメインの config.xml ファイルや、startWeblogic.cmd などのドメイン バッチ スクリプトに組み込まれます。
チーム メンバーは、ソース コントロールを使用してこれらのドメイン ファイルを共有します。これによって、既存のデプロイ済みアプリケーションに対するすべての変更内容、新規アプリケーションの追加、および config.xml に格納されているその他の設定や起動スクリプトを共有できるようになります。
注意 : 開発環境において、複数のドメイン コンフィグレーション設定が必要であり、解決策としてコンフィグレーション ファイル テンプレートを利用しようとしている場合は、config.xml をソース コントロールの中に格納しないでください。詳細については、「コンフィグレーション ファイル テンプレート (config-template.xml) の設定」を参照してください。
config.xml および startWebLogic.cmd のコードの一部を次に示します。ここでは、パスがハードコード化されています。
<Application Name="JWSQueueTransport" Deployed="true"
LoadOrder="1000" Path="C:\bea812\weblogic81\server\lib\" TwoPhase="true">
<EJBComponent Name="QueueTransportEJB" Targets="portalServer"
URI="QueueTransportEJB.jar"/>
</Application>
set DOMAIN_HOME=C:\bea812\weblogic81\samples\domains\portal
config.xml ファイルおよび startWeblogic.cmd ファイルがソース コントロールの中で共有されている場合は、すべてのチーム メンバーが、これらのファイル内で記述されているパスに WebLogic Server をインストールしている必要があります。ただし、開発者が特定のドライブに WebLogic Server をインストールできないこともあります。たとえば、複数のパーティションがあり、C ドライブの空き容量が十分でない場合です。
さらに、ドメイン ルート ディレクトリにある pointbase.ini というコンフィグレーション ファイルに documentation.home プロパティが含まれており、このプロパティが指すファイル システム上の場所がハードコード化されている可能性もあります。
表 3-1 に、ドメイン内のファイルのうち、パスがハードコード化されているものを示します。
次の節では、チーム メンバー全員が同じ BEA ホーム ディレクトリを使用することが不可能な場合の方法を説明します。
チーム メンバー全員が同じ BEA ホーム ディレクトリを使用できる場合は、「ポータル ドメインの作成と共有」に進んでかまいません。
チーム メンバーがそれぞれ異なる BEA ホーム ディレクトリを使用する場合にドメインを共有するには、以下に説明するようにさまざまな手法があります。
コンフィグレーション ファイル テンプレートを作成すれば、他の方法に伴う問題の多くを回避できますが、config.xml および他のファイルに対する検索と置換の処理を実装する必要があります。BEA ホーム ディレクトリを表すトークンが含まれている config.xml のテンプレートを作成することによって、そのテンプレートと、開発者が指定したトークン値の組み合わせから config.xml を作成するプロセスを作成できます。
コンフィグレーション ファイル テンプレートは、マシンに複数の BEA ホーム ディレクトリを設定する以外にも、多くの目的に使用できます。テンプレートにすることによって、各開発者が、共通のデータ ソース コンフィグレーションを使用する個別のデータベース インスタンスで作業できます。
コンフィグレーション ファイル テンプレートを使用する場合、config.xml はソース コントロールに格納されません。コンフィグレーション ファイル テンプレートの設定方法については、「コンフィグレーション ファイル テンプレート (config-template.xml) の設定」を参照してください。
Windows ベースの開発者は、代替ドライブ文字を設定して、自分の BEA ホーム ディレクトリにマップすることもできます。
Windows のコマンド プロンプトから、仮想ドライブを作成して既存のドライブおよびパスにマップするには、subst コマンドを使用します。現在使用していない仮想ドライブ文字をチームの共通ドライブとしてコンフィグレーションし、アプリケーションやドメインのアクティビティにそのドライブ文字を使用します。
たとえば、ドライブ文字 P: を作成し、C: ドライブ上のディレクトリ (たとえば C:¥bea812) にマップするには、Windows コマンド プロンプトから次のコマンドを実行します。
subst P: C:\bea812
これで、新規ドメインの作成後に、表 3-1 に示したドメイン ファイルでの C:\bea812 への参照をすべて P: に変更できます。
この方法では、前述の config.xml および startWebLogic.cmd のエントリは次のようになります。変更箇所は太字で強調表示されています。
<Application Name="JWSQueueTransport" Deployed="true"
LoadOrder="1000" Path="P:\weblogic81\server\lib\" TwoPhase="true">
<EJBComponent Name="QueueTransportEJB" Targets="portalServer"
URI="QueueTransportEJB.jar"/>
</Application>
set DOMAIN_HOME=P:\weblogic81\samples\domains\portal
注意 : ハードコード化された新しいパスに C:\bea812 が含まれていないのは、subst コマンドによって C:\bea812 が P: にマップされたからです。
このドメインを使用するときは、P ドライブに切り替えてドメイン ディレクトリに移動します。別の開発者が WebLogic Server を D:¥bea にインストールする場合は、subst P: d:¥bea を実行してそのディレクトリを P:¥ で置き換えるだけで、同じ config.xml を共有してスクリプトを起動できるようになります。
subst コマンドを実行しなければなりません。ただし、このコマンドをテキスト ファイル内に入力し、そのファイルに .cmd という拡張子を付けて保存し、プログラムの \Startup フォルダに置くことによって、システム起動時に自動的にコマンドが実行されます。link コマンドを使用できます。チーム メンバーが、同じドライブ上のそれぞれ異なるパスにインストールする必要があり、WebLogic Server ディレクトリに対して共通の相対パス上にドメインおよびアプリケーションが配置されている場合は、config.xml 内のすべてのファイル パスと起動スクリプトを相対パスに変更できます。ただし、この方法はそのスコープ内に限定されます。
ドメインが C:\bea812r_projects\mydomain にインストールされているとき、この方法では、前述の config.xml および startWebLogic.cmd のエントリは次のようになります (変更箇所は太字で強調表示されています)。
<Application Name="JWSQueueTransport" Deployed="true"
LoadOrder="1000" Path="..\..\weblogic81\server\lib\" TwoPhase="true">
<EJBComponent Name="QueueTransportEJB" Targets="portalServer"
URI="QueueTransportEJB.jar"/>
</Application>
set DOMAIN_HOME=..\..\weblogic81\samples\domains\portal
チーム リードが実行する最初の手順は、新規のポータル ドメインの作成です。ドメインの作成は複数のフェーズから構成されています。このとき、独自のドメイン テンプレートを作成、ドメインの Configuration Wizard プロセスの実行、ソース コントロールへの初回チェックイン、ドメインのコンフィグレーションが可能になります。
drive:\ourDomain のような短いパスで格納します。たとえば、ドメインを WEBLOGIC_HOME\user_projects\PROJECT\domain\DOMAIN にインストールします。
アプリケーションは、WEBLOGIC_HOME\user_projects\PROJECT\application\APP にインストールします。
注意 : 実際のパスはこれより短くても、あるいは BEA インストール階層の外部にあるものでもかまいません。
この方法では、ソース コントロール システムのプロジェクトの共通のルート ディレクトリ (%PROJECTNAME) を、ドメインとアプリケーションの両方に対して使用できます。
startWebLogic スクリプトをテキスト エディタで開き、if "%WLS_REDIRECT_LOG%" 行の前に WLS_REDIRECT_LOG ファイルへのパスを追加します。次に例を示します。WLS_REDIRECT_LOG=D:\logs\admin
if "%WLS_REDIRECT_LOG%"=="" (
startWeblogic コマンドを使用してドメインを起動します。サーバが稼動している状態でドメインをコンフィグレーションし、プロジェクトですぐに使用することもできます。ドメインが開発チームをサポートするように、WebLogic Server Administration Console (http://server:port/console) を使用して設定します。たとえば、必要なデータ ソースを追加します。開発ドメインの一般的なチューニング作業には、サーバのロギング モードを「Warn」から「Info」に変更する (コンソール出力が冗長化され、JVM メッセージがコンソールに出力される) ことなどがあります。また、ログ ファイルの最大サイズは制限できます。
サーバ コンフィグレーションの詳細については、「システム管理」を参照してください。
サーバ コンフィグレーションに変更を加えた後で、config.xml (またはテンプレートの config-template.xml を手作業で修正したもの) をチェック インします。
ソース コントロールから除外するドメイン ファイルは以下のとおりです。
|
|
|
WebLogic Server ドメインを正しく機能させるには、ドメインのバイナリ ファイルの多くをソース コントロール管理にチェック インする必要があります。このようなバイナリ ファイルは、時間がたつにつれて、ユーザの操作や、インデックス ファイルの増加などが原因で変更されることがあります。そのため、バイナリ ファイルがどのようなものであり、なぜ変化するか、およびいつチェック インまたはチェック アウトするかを、開発者がよく理解しておくことが重要です。この節では、ソース コントロール管理においてこのようなファイルをいつ更新するかを判断する方法を中心に説明します。更新できるバイナリ ファイルの種類として、LDAP ファイル、セキュリティ関連ファイル、およびデータベース コンフィグレーション ファイルがあります。
ソース コントロールの中でバイナリ ファイルを共有できるようにするには、ファイルに変更を加えるときに常に同じプロセスに従う必要があります。バイナリへの変更を加えるユーザは 1 人だけ (一般にはチーム リード) とします。このようにすれば、プロジェクト ライフサイクルにおいて結合が発生したときの競合を抑えることができます。
ソース コントロール内のドメイン バイナリ ファイルを修正するには、次の手順を実行します。
開発における一般的なアクティビティの 1 つに、システムのテストに使用する基本的なユーザ セットの作成があります。デフォルトでは、ユーザ、グループ、ロール、および資格の情報は、BEA が提供する LDAP サーバに格納されます。この LDAP サーバのデータ ストアは、ファイル システムの domain/ldap ディレクトリ内に永続的に保存されます。
BEA の LDAP サーバの詳細については、「組み込み LDAP サーバの管理」を参照してください。
この LDAP サーバにはチーム メンバーによる共有が必要な情報が格納されているので、LDAP ディレクトリにあるファイルをソース コントロールにチェック インします。ただし、バックアップおよびログのファイルを除きます (表 3-2 を参照してください)。プロジェクト開発の進行中に、既存のユーザ、グループ、ロール、および資格が変更されることもあります。WebLogic Administration Portal を使用してユーザ、グループ、ロール、および資格をコンフィグレーションし、更新された LDAP ファイルをソース コントロールにチェック インします。
WebLogic Administration Portal の使用手順については、『ポータル管理入門』を参照してください。
ドメイン内に存在するその他の重要なセキュリティ ファイルは、SerializedSystemIni.dat、DefaultAuthenticatorInit.ldift、DefaultAuthorizerInit.ldift、および DefaultRoleMapperInit.ldift ファイルです。これらのファイルには、ドメインの起動に必要となる重要なセキュリティ情報が格納されています。これらのファイルは、一般に、開発中に変更されることはありませんが、サーバを起動するにはこれらのファイルが存在している必要があります。ドメイン ルートにある boot.properties ファイルには、ドメインを起動するためのユーザ名およびパスワードの情報が暗号化されて格納されます。このファイルは必須ではありませんが、一般に、開発環境で認証の必要なしにサーバ起動を許可するために使用されます。
WebLogic Portal のコンフィグレーション情報の多くはデータベース内に格納されますが、開発チームがこのコンフィグレーションへのアクセスを共有しなければならないこともあります。ただし、WebLogic Portal は、1 つのポータル サーバの複数のインスタンスを単一の同じデータベース サーバまたはデータベース スキーマに対して実行することはサポートしていません。WebLogic Portal ドメインのデフォルトのデータベースは PointBase ですが、異種データベース間でのデータの移動は非常に手間のかかる手作業となることがあるため、開発過程ではエンタープライズ品質のデータベースを使用することをお勧めします。「エンタープライズ品質データベースを使用して開発する」を参照してください。
新しいポータル ドメインを作成すると、PointBase データベースのインスタンスが 1 つ作成され、そのドメインのルート ディレクトリ内に永続的に保存されます。また新しいドメインはエンタープライズ品質のデータベースに必要なデータベース オブジェクトを作成します。Oracle、SQL Server、DB2、または Sybase のデータベースのコンフィグレーションの詳細については、『データベース管理ガイド』を参照してください。新しいドメインの作成の詳細については、『コンフィグレーション ウィザードの使い方』を参照してください。
このデータベースには多数のテーブルがあり、ベース WebLogic Portal および WebLogic Workshop のデータが格納されます。WebLogic Portal の各コンポーネントに対応するデータベース オブジェクトの説明については、「データ ディクショナリ」を参照してください。さらに、WebLogic Workshop の内部ステートの一部もデータベースに格納されます。WebLogic Workshop ヘルプ システムの「内部ステート用に別のデータベースを使用するように WebLogic Workshop をコンフィグレーションするには」では、この内部ステート ストアを別のデータベースに移動する方法を取り上げています。
PointBase ではデータベースをファイル システムに永続的に保存するために、workshop$1.wal と workshop.dbn の 2 つのファイルを使用します。データベースはファイル システムに永続的に保存されるので、データベースのコピーの共有は、ソース コントロール管理を使用して簡単に実現できます。ただし、PointBase を使用すると、時間と共に PointBase ファイルのサイズが増加します。つまり、そのファイルは常に、ユーザによって変更が加えられたように見えるということです。時間が経過するにつれて、PointBase のファイルのサイズはおよそ 3 MB から 10 MB 以上に増加します。開発者は、WebLogic Administration Portal または PointBase Console を使用して明示的にデータを直接変更する場合を除いてデータベースをチェック インしないように注意する必要があります。変更を加える必要があるときは、次の手順で示すプロセスに従うことによって、更新内容のサイズを最小限に抑えてください。
前回のチェック アウト以降に PointBase ファイルのサイズが大幅に増加している可能性もあるため、このことは特に重要です。新しいチェック アウトによって、このようなファイルのサイズを小さくしてから、追加を行います。
一般に、WebLogic Administration Portal を使用して行うアクティビティのほとんどは、PointBase データベースに永続的に保存されますが、ユーザ データ、グループ データ、資格、および委託管理ポリシーは、組み込み LDAP に永続的に保存されます。ただし、データベースに格納されているユーザ プロパティを持つテスト ユーザで開発を行う場合もあります。
PointBase データベースをバイナリ ファイルとして開発者間で共有するのではなく、Oracle や SQL Server などのエンタープライズ品質データベースを使用して、各開発者がポータル データベースのユニークな自分専用のインスタンスを使用して作業することが一般的です。
プロダクションで使用するエンタープライズ品質の DBMS と同じものを、開発でも使用する必要があります。たとえば、Oracle でアプリケーションをデプロイする場合には、アプリケーションも Oracle で開発する必要があります。
注意 : Oracle と DB2 では、開発データベース インスタンスについては、開発者ごとに別のデータベース スキーマを使用することをお勧めします。Sybase と SQL Server では、開発データベース インスタンスについては、開発者ごとに別のデータベースとデータベース ログ ファイルを使用することをお勧めします。
この方法により、パフォーマンスが向上し、データのベースラインの保守が簡単になります (データベース管理者の適切なサポートとスクリプトが必要)。
開発マシンはそれぞれ特定のデータベースを使用するようにコンフィグレーションされます。この情報を格納する config.xml は、ソース コントロール管理内の共有ファイルです。開発者間で config.xml を共有し、各開発者のユニークなデータベース インスタンスへの参照を維持する方法については、「コンフィグレーション ファイル テンプレート (config-template.xml) の設定」を参照してください。
情報を共有するには、開発者が自分のデータベース スキーマのインスタンスを保存できるようなプロセスを、データベース管理者が設定します。このスナップショットを他の開発者が自分のスキーマに適用できるように、別のプロセスを設定します。データベースの一部分のスナップショット、あるいは DDL スクリプトの共通セットを保存することも一般的に行われています。
WebLogic Portal の各コンポーネントに対応するデータベース オブジェクトの説明については、「データ ディクショナリ」を参照してください。
さらに、WebLogic Workshop の内部ステートの一部もデータベースに格納されます。WebLogic Workshop ヘルプ システムの「内部ステート用に別のデータベースを使用するように WebLogic Workshop をコンフィグレーションするには」では、この内部ステート ストアを別のデータベースに移動する方法を取り上げています。
ポータル ドメインをコンフィグレーションしたら、チーム リードは新しいポータル アプリケーションを作成する必要があります。アプリケーションの作成にはいくつかのフェーズがあります。たとえば、アプリケーションを作成し、WebLogic Workshop を使用して任意の数のポータル Web プロジェクトを作成し、ソース コントロールへの初回チェック インを行います。
新しいポータル アプリケーションおよびポータル Web プロジェクトを作成する手順については、「ポータル アプリケーションおよびポータル Web プロジェクトを作成する」を参照してください。
コマースおよびパイプラインなどのアプリケーションに必要なサービスや、コマースおよび Webflow (従来のポータル Web アプリケーションへの対応に必要) などの各ポータル Web プロジェクト内に必要なタグ ライブラリを必ずインストールしてください。
「チームが共有するポータル ドメイン作成のベスト プラクティス」で述べたように、ドメイン ディレクトリとアプリケーション ディレクトリを共通の親ディレクトリに配置すると、ソース コントロール管理システムでのこれらのディレクトリの共有を簡単に管理できるようになります。
たとえば、ドメインを drive:\ourDomain にインストールし、アプリケーションを drive:\ourApp にインストールします。
この方法では、ソース コントロール システムのプロジェクトの共通のルート ディレクトリ (%PROJECTNAME) を、ドメインとアプリケーションの両方に対して使用できます。
注意 : パス長の例外を回避するために、ドメインとアプリケーションの各ディレクトリは短いパスで格納してください。たとえば、drive:\ourDomain と指定します。
WebLogic Workshop アプリケーションの構築が完了したら、チーム リードはアプリケーションをソース コントロールにチェック インします。これは、アプリケーションのビルドの前に行います。ビルドの実行時に多数のファイルが作成されますが、これらのファイルはソース コントロールにチェック インしてはならないからです。
ソース コントロールから除外するアプリケーション ファイルは以下のとおりです。
ソース コントロールから除外されるファイルには、コンパイル済み JAR、一時コンフィグレーション ファイル、WebLogic Workshop の出力ディレクトリなどがあります。
ソース コントロール管理と WebLogic Workshop アプリケーションを使用して作業するときの基本的な考え方は、アプリケーションのチェック アウト、ビルドの開始、およびエラーなしでのサーバの起動を開発者が実行できるようにするというものです。
WebLogic Workshop でビルドを開始すると、多数の JAR ファイルおよび一時ディレクトリが WebLogic Workshop アプリケーションの内部に作成されます。表 3-3 に、これらのファイルを示しています。さらに、コントロールに対応するステートレス セッション bean などのファイルが、アプリケーションの .workshop ディレクトリに作成されます。このステートレス bean の名前は、多くの場合、TimerControl_-1n8kn2z7skxv のようになっています。
WebLogic Workshop によってアプリケーションがドメインにデプロイされるとき、config.xml にアプリケーションが登録されます。このデプロイメントは、サーバが起動されたときと、アプリケーションがビルドされたときに自動的に行われます。この時点で、アプリケーションは config.xml の新しい XML ブロックとして追加されます。
コード リスト 3-1 に、portalpm という名前のアプリケーションについて config.xml に追加されるブロックを示します。
コード リスト 3-1 config.xml ファイルに追加されるアプリケーション
<Application Name="portalpm" Path="P:\user_projects\applications"
StagingMode="nostage" TwoPhase="true">
<WebAppComponent Name="portalpmAdmin" Targets="portalServer"
URI="adminPortal.war"/>
<EJBComponent Name="content.jar" Targets="portalServer"
URI="content.jar"/>
<EJBComponent Name="content_repo.jar" Targets="portalServer"
URI="content_repo.jar"/>
<WebAppComponent Name="portalpmDatasync" Targets="portalServer"
URI="datasync.war"/>
<EJBComponent Name="netuix.jar" Targets="portalServer"
URI="netuix.jar"/>
<EJBComponent Name="p13n_ejb.jar" Targets="portalServer"
URI="p13n_ejb.jar"/>
<EJBComponent Name="prefs.jar" Targets="portalServer"
URI="prefs.jar"/>
<WebServiceComponent Name="portalpmTool" Targets="portalServer"
URI="wps-toolSupport.war"/>
<EJBComponent Name="wps.jar" Targets="portalServer" URI="wps.jar"/>
<ApplicationConfiguration Name="portalpm" Targets="portalServer"/>
</Application>
WebLogic Workshop によってドメインの config.xml が自動的に更新されるので、アプリケーション名の XML ブロックが含まれる config.xml をチェック インする必要はありません。代わりに、開発者はアプリケーションをチェック アウトし、ビルドを行い、このアプリケーション参照がない状態のドメインでサーバを起動します。その後で、この開発者のアプリケーションが config.xml にデプロイされるとき、新しくビルドされたアプリケーション コンポーネントへの必要な参照がすべて作成されます。config.xml を使用してアプリケーション名の XML ブロックをチェック インした場合は、コンポーネントの追加や削除が必要であれば、自動的にこのファイルが更新されます。
注意 : 「コンフィグレーション ファイル テンプレート (config-template.xml) の設定」で説明しているように、コンフィグレーション ファイル テンプレートを使用している場合は、コンフィグレーション ファイル テンプレートを使用して基本の config.xml が個々の開発マシン上にすでに作成されており、アプリケーションの変更や追加は各開発者の config.xml ファイルに正しく追加されます。
アプリケーションのコンポーネントを格納するファイルには、この他に、application.xml と weblogic-application.xml の 2 つがあります。これらのファイルは、アプリケーションの META-INF ディレクトリにあります。これらのファイルをソース コントロール内で共有する必要があります。また、新規コンポーネントをアプリケーションに追加するとき (新しい EJB など)、更新された application.xml および weblogic-application.xml をソース コントロールに再びチェック インする必要があります。
この節では、ポータル アプリケーションのソース コード格納に関するベスト プラクティスを紹介します。
多数の汎用 Java ライブラリをポータルで使用する場合は、ポータル エンタープライズ アーカイブ内の Java プロジェクトに Java ライブラリを格納することをお勧めします。このようにすれば、サーバの複数のインスタンスに Java ライブラリを移植することが可能になり、ライブラリを再利用するためのパッケージ化も容易になります。
クロスプラットフォーム環境での開発とデプロイにおけるコーディングでは、以下のベスト プラクティスに従ってください。
myPortletContent.jsp というファイルを作成し、Windows 上でコンテンツ URI としてファイル MyPortletContent.jsp を指定しても問題ありません。ただし、この同じアプリケーションを UNIX 上にデプロイすると、ファイル MyPortletContent.jsp が見つからないというエラーが発生します。ブック、ページ、およびポートレットを WebLogic Workshop のポータル デスクトップに追加すると、定義ラベル (ユニークな ID) が各コンポーネントごとに自動的に生成されます (これは [プロパティ エディタ] ウィンドウに表示されます)。複数の開発者が新しいポータル コンポーネントを作成していると、異なるコンポーネントに対して同一の定義ラベルが自動的に生成される場合があります。定義ラベルの重複を避けるには、命名規約を使用して新しいコンポーネントごとに手動で定義ラベルを変更します。
作成したコードは、クラスタ環境において十分にテストしてください。また、セッション データが管理可能なサイズを超えないように維持することや、クラスタ全体でのセッション共有をサポートするように Web アプリケーションをコンフィグレーションすることも重要です。クラスタ化情報については、「ポータル クラスタのコンフィグレーション」を参照してください。
チーム開発環境で作業するときは、チーム メンバーが同じ config.xml ファイルを使用する必要があります。これは、既存のデプロイ済みアプリケーションへの変更や、新規アプリケーションの追加、および config.xml ファイルに格納されるその他の設定が共有されるようにするためです。ただし、ユーザごとに内容が異なるコンフィグレーション設定もあります。この変動が最も大きくなるのは、開発者がそれぞれ異なる BEA ホーム ディレクトリを使用しているときや、自分専用のデータベース インスタンスを使用しているときです。一般に、開発者はそれぞれ異なるデータベース ログインを持っており、JDBC 接続プールに対してもそれぞれ異なる設定を必要とします。
コンフィグレーション ファイル テンプレートは、テンプレートのドメイン コンフィグレーション ファイル config-template.xml を配布することによってこの問題を解決するものです。開発者は、ソース コントロールを通してこの config-template.xml ファイルを共有します。
各開発環境でユニークなドメイン コンフィグレーションが必要な場合は、config.xml ファイルをソース コントロールから除外します。代わりに、config-template.xml をチェック インしてください。
ant などのスクリプト言語を使用して、config-template.xml を config.xml ファイルに上書きコピーするプロセスを設定します。次に、config.xml ファイル内の特定の文字列を、プロパティ ファイル内で各開発者が定義した文字列で置き換えます。
たとえば、config-template.xml ファイルの内容が次のとおりであるとします。
<JDBCConnectionPool DriverName="weblogic.jdbc.oci.Driver"
MaxCapacity="10" Name="Arcadia"
Properties="user=ARCADIAUSER;password=ARCADIAPASSWORD;server=arcadia"
RefreshMinutes="10" Targets="myserver"
また、あるユーザの local.configtemplate.properties ファイルに、次の 2 つのエントリがあるとします。
ARCADIAUSER=john
ARCADIAPASSWORD=mypassword
置換プロセスの実行後、このユーザの config.xml ファイルの内容は次のようになります。
<JDBCConnectionPool DriverName="weblogic.jdbc.oci.Driver"
MaxCapacity="10" Name="Arcadia"
Properties="user=john;password=mypassword;server=arcadia"
RefreshMinutes="10" Targets="myserver"
各ユーザに必要なのは、local.configtemplate.properties ファイルの自分専用のコピーを保持することだけですが、このファイルはソース コントロールにチェック インしてはなりません。configtemplate.properties という名前のファイルをソース コントロールに配布します。これは、有効な local.configtemplate.properties ファイルのサンプルとなるものです。
単一クラスタ ドメインで複数のエンタープライズ アプリケーションを作成および実行できます。図 3-1 に示すように、単一のドメインで複数のエンタープライズ アプリケーション (EAR) をホストできます。各 EAR デプロイメントで複数の Web アプリケーションをホストでき、Web アプリケーションに応じて任意の数のデスクトップを作成できます。1 つのエンタープライズ アプリケーション (EAR) に関連付けられている Web アプリケーションおよびデスクトップは、別のエンタープライズ アプリケーションにある (切り離されている) Web アプリケーションおよびデスクトップに依存しません。
図 3-1 単一ドメイン内の複数のエンタープライズ アプリケーション
単一ドメインに複数のエンタープライズ アプリケーションをコンフィグレーションする場合、次の制限が適用されます。
context-root 名とそれに関連する CookieName 名にも適用されます。各エンタープライズ アプリケーションの WebLogic Administration Portal に、サーバにデプロイされているすべてのポータル Web アプリケーションが表示されます。 注意 : 各エンタープライズ アプリケーションは、それぞれの Administration Portal を通じて管理する必要があります。コンテンツ、ユーザ、グループなどの一部のドメインレベルのリソースは、エンタープライズ アプリケーションに関係なく、単一の Administration Portal から表示および管理できますが、アプリケーションのデータはキャッシュされていることがあり、そのデータに対して別のアプリケーションの Administration Portal から行われた更新は即時に表示されない場合があることに注意してください。
注意 : 各エンタープライズ アプリケーションのコンテンツは、それぞれのポータル管理ツールと仮想コンテンツ リポジトリを通じて管理されます。仮想コンテンツ リポジトリ (およびポータル管理ツール) は、各アプリケーションに対してユニークであり、共有できません。
SP4 より前のリリースでは、クラス ファイルは WebLogic Workshop によってパス WEB-INF/classes に自動的にビルドされるため、このパスにはクラス ファイルを格納しないことが推奨されていました。ただし、SP4 では、次の新しいクラスがパスに追加されました。
これらのクラスのソース ファイルは提供されていません。具体的には次のクラスです。
PortalManager.class PortalLogger.class PortalBeanManager.class PortalAdminLogger.class DefaultPortalLogger.class この変更により、WebLogic Workshop に基づく SP4 のポータル プロジェクトは、ソース コントロール リポジトリから抽出される場合は正常にビルドされません。
ソース コントロールを使用した場合にポータル プロジェクトを正常にビルドできるようにするには、上記のクラス ファイルを含む .jar ファイルを作成し、その .jar ファイルをソース コントロール システムのリポジトリにチェックインします。
|
|
|