| Oracle® Fusion Middleware Oracle JDeveloperによるWebCenter Portalアセットとカスタム・コンポーネントの開発 12c (12.2.1.1) E79323-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle JDeveloperによるWebCenter Portalアセットとカスタム・コンポーネントの開発 12c (12.2.1.1) E79323-01 |
|
|
前 |
次 |
この章の内容は次のとおりです。
WebCenter Portalでは、JSR 286標準を使用した標準ベースのJavaポートレットの作成をサポートしています。
JSR 286は、ポートレットとポータル間の相互運用を可能にし、集約、パーソナライズ、表示形式およびセキュリティの各領域に対処する一連のAPIを定義する仕様です。JSR 286では、次の機能を提供するコンテナ・サービスを定義しています。
ポートレット機能をコーディングするためのポートレットAPI
ポートレット・コンテナ内でユーザー相互作用を作成するためのURLリライティング・メカニズム
ポートレットのセキュリティとパーソナライズ
ポートレット・イベントおよびパブリック・レンダラ・パラメータを使用したポートレット間通信
詳細は、次の場所にあるJSR 286の仕様を参照してください。
http://jcp.org/en/jsr/detail?id=286
WSRPは、Webサービスの標準です。この標準によって、ポータルまたは他の中間Webアプリケーションを使用するユーザー対象のWebサービスで視覚的なプラグ・アンド・プレイが可能になります。WSRPは標準であるため、標準コンテナとあらゆるWSRPポータル間の相互運用性が実現されます。WSRPでは、次の項目を定義しています。
WSRPサービスを起動するためのWeb Services Definition Language (WSDL)インタフェース
WSRPサービスで発生するマークアップのためのマークアップ・フラグメント・ルール
WSRPサービスとメタデータを公開、検索およびバインドするメソッド
WSRPは、ポートレット・クライアントと、リモート・サーバーで実行されているポートレット・コンテナとの間の通信を可能にします。JSR 286には、ポートレット・プロデューサ・アプリケーションを実行するためのJavaポートレットAPIについての記述があります。これらの標準を組み合せることで、開発者は、内部または外部のソースからのアプリケーションをポートレットとしてWSRPポータルに統合できます。ページの構築は、JDeveloperの「リソース・パレット」やアプリケーション・ナビゲータの「アプリケーション・リソース」ペインからポートレットを選択するのと同様に簡単に行えるようになりました。
図13-1に、JSR 286ポートレットを使用するWSRP仕様のアーキテクチャを示します。
WebCenter Portalには、JDeveloperで使用できるウィザードが用意されており、このウィザードを使用すると、JSR 286標準ベースのJavaポートレットの初期フレームワークを短時間で簡単に作成できます。
JSR 286 Javaポートレットの作成ウィザードでは、実装するポートレット・モードと、各モードに使用する実装メソッド(JSP、HTTPサーブレット、JavaクラスまたはHTML)を選択できます。さらに、ウィザードによって、選択したモードごとに簡単な実装を作成します。
JDeveloperのウィザードを使用してJSR 286 Javaポートレットを作成するには:
JDeveloperで、ポートレットの作成先であるポートレット・プロデューサ・アプリケーションを開くか、新しいポートレット・プロデューサ・アプリケーションを作成します。
ポートレット・プロデューサ・アプリケーションの作成方法の詳細は、「ポートレット・プロデューサ・アプリケーション」を参照してください。
注意:
WebCenter Portal - ポートレット・プロデューサ・アプリケーション・テンプレートを使用せずに、ポートレット・プロデューサ・アプリケーションを作成する場合は、テクノロジ・スコープを構築する適切なポートレットをアプリケーションに手動で追加する必要があります。
ポートレットを作成するプロジェクト(たとえば、「ポートレット」)を右クリックして、「新規」を選択します。
「新規ギャラリ」(図13-2)で「Web層」を開き、「ポートレット」、「規格に基づいたJavaポートレット(JSR 286)」の順に選択して、「OK」をクリックします。
図13-2 「新規ギャラリ」の「規格に基づいたJavaポートレット(JSR 286)」オプション
ヒント:
プロジェクトにJSR 286ポートレットが含まれている場合は、次の方法でも新しいポートレットを作成できます。
portlet.xmlを右クリックして、「ポートレットの追加」を選択します。
portlet.xmlを開き、「設計」タブをクリックして、「ポートレット」タブの「追加」アイコンをクリックします。
JSR 286 Javaポートレットの作成ウィザードの「一般ポートレット情報」ページで、「名前」フィールドに入力されているデフォルト名を変更して、ポートレットの用途を適切に表すようにします。
「クラス」フィールドに、ポートレットのクラスの名前を入力します。表示されているデフォルト名を受け入れることも、独自の名前を指定することもできます。新しい名前を入力する場合は、有効なJava名を使用する必要があります。
「パッケージ」ドロップダウン・リストから、クラスを作成するパッケージを選択するか、パッケージの名前を入力します。
必要に応じて、「参照」ボタンをクリックして、プロジェクト内のパッケージを検索します。特定のパッケージを選択しないと、ウィザードではプロジェクトのデフォルト・パッケージが使用されます。
「言語」ドロップダウン・リストから、ポートレットでサポートするデフォルト言語を選択します。ウィザードでは、デフォルトで英語が使用されます。
ポートレットで「編集」モードをサポートするには、「ユーザーがポートレット・コンテンツを編集できるようにします」を選択します。ウィザードでは、このオプションがデフォルトで選択されています。
編集モードを使用すると、ユーザーは実行時にポートレットをパーソナライズできるようになります。詳細は、「編集モード」を参照してください。
このオプションを選択すると、ポートレットの編集モードについて実装の詳細を後からウイザードで指定できるようになります。
「Next」をクリックします。
「追加ポートレット情報」ページの「ポートレット・タイトル」フィールドに、ポートレットの説明的なタイトルを入力します。
ポートレット・タイトルは、リソース・カタログに表示されるため、ポートレットが便利かどうかどうかをユーザーが判断するのに役立つタイトルにしてください。ポートレットのタイトルは、ポートレットがページに表示されるとポートレットのヘッダーにも表示されます。
ヒント:
「表示名」、「短いタイトル」、「説明」、および「キーワード」の各属性は、WebCenter Portalには実装されていません。これらのフィールドに、値を入力する必要はありません。ただし、そのポートレットが別のアプリケーションで利用される可能性がある場合を除きます。
ウィザードのこの時点で、「終了」をクリックし、残りのすべての設定にデフォルト値を使用することで、ポートレットをすぐに作成できます。
ポートレットにその他の詳細を指定するには、「次へ」をクリックし、残りの手順を実行します。
「コンテンツ・タイプとポートレット・モード」ページの「コンテンツ・タイプとポートレット・モード」リストで、「表示」を選択します。
「実装メソッド」セクションで、ポートレットの表示モードの実装方法を次から選択します(表示モードの詳細は、「表示モード」を参照)。
JSPの生成: そのポートレット・モードに応じたスケルトンJSPファイルを生成する場合に選択します。対応するフィールドにJSPの名前を入力するか、デフォルトを受け入れます。
ウィザードを完了すると、生成されたJSPがアプリケーション・ナビゲータに表示されます。このJSPは、今後の開発の際にアプリケーション・ナビゲータから選択できます。これは、すべてのポートレット表示モードのデフォルトの選択です。
ADF-Faces JSPXの生成: ADF-Facesコンポーネントの追加が可能なページを生成する場合に選択します。対応するフィールドにJSFページの名前を入力するか、デフォルトを受け入れます。
このオプションを選択すると、ポートレットの実装クラスは、oracle.portlet.bridge.adf.application.ADFBridgePortletのサブクラスとして作成されます。javax.portlet.GenericPortletのサブクラスとしては作成されません。つまり、このウィザードで、Oracle JSF Portlet Bridgeを使用するポートレット・プロデューサ・アプリケーションを生成することになります。Oracle JSF Portlet Bridgeの詳細は、「Oracle JSF Portlet Bridgeを使用したJSFアプリケーションからのポートレットの作成」を参照してください。
パスへのマップ: ポートレット・モードを、ポートレット・プロデューサ・アプリケーションのWebリソース(ページなど)にマップする場合に選択します。このリソースは、このウィザードでは生成されません。対応するフィールドに名前とパスを入力します。このリソースは、ウィザードの完了後に必要に応じて作成できます。
これを選択するときは、ターゲットのリソースまたはファイルを作成する必要があります。ターゲットとしては、JSP、サーブレット、HTMLファイルなどを使用できます。これを選択すると、生成されるポートレットJavaクラスには、特定のモードに対するリクエストを指定したターゲットにルーティングするコードが入力されます。
カスタム・コード: カスタム・コード・オブジェクトでポートレット・モードを実装する場合に選択します。このオブジェクトは、後で作成する必要があります。これを選択すること、生成されるポートレットJavaクラスに、コンテンツをレンダリングするためのスケルトン・メソッド(private void doMODE_NAMECONTENT_TYPE)を生成します。役に立つコンテンツをレンダリングするには、このコードを更新する必要があります。
ヒント:
このポートレット・モードで別のコンテンツ・タイプ(text/xmlなど)もサポートする場合は、手順16を参照してください。
ウィザードの最初のページで「ユーザーがポートレット・コンテンツを編集できるようにします」を選択した場合は、「編集」を選択して、手順13で説明したように、編集モードに応じた実装方法を選択します(編集モードの詳細は、「編集モード」を参照)。
ポートレットに別のポートレット・モードを実装するには:
「コンテンツ・タイプとポートレット・モード」リストの該当するコンテンツ・タイプ(たとえば、text/html)で、既存のモード(たとえば、「表示」)を選択します。
「追加」をクリックします。
「ポートレット・モード」ダイアログで、「選択済」リストに必要なモードを1つ以上移動して、「OK」をクリックします。
「ポートレット・モード」ダイアログには、JSR 286でサポートされる標準のモードと、WebCenter Portalでサポートされる拡張モードが一覧表示されます。
詳細は、「ポートレット・モード」を参照してください。
ポータル・モードをそれぞれ選択して、コンテンツのレンダリングに使用する実装メソッドを指定します。手順13を参照してください。
コンテンツ・タイプによって、ポートレットでサポートされるコンテンツのタイプが識別されます。ポートレットでは、複数のコンテンツ・タイプをサポートできます。JSR 286 Javaポートレットの作成ウィザードを使用して作成されたポートレットでは、text/htmlコンテンツ・タイプがデフォルトでサポートされます。
異なるコンテンツ・タイプを追加するには:
「コンテンツ・タイプとポートレット・モード」リストで、既存のコンテンツ・タイプ(たとえば、text/html)を選択します。
「追加」をクリックします。
「コンテンツ・タイプ」ダイアログで、「選択済」リストに必要なコンテンツ・タイプを移動して、「OK」をクリックします。
text/html: テキストのHTMLエンコードをサポートします。これはデフォルト選択です。
text/xml: テキストのXMLエンコードをサポートします。
text/plain: エンコードされていないプレーン・テキストをサポートします。
text/vnd.oracle.mobilexml: テキストのOracle Mobile XMLエンコードをサポートします。ただし、WebCenter PortalではOracle Mobile XMLはサポートされません。
application/xhtml+xml: テキストのXHTMLエンコードをサポートします。
application/xml: XHTMLを含むXMLコンテンツをサポートします。
「Next」をクリックします。
ウィザードの前のほうの「一般ポートレット情報」ページで、「ユーザーがポートレット・コンテンツを編集できるようにします」を選択した場合は、ポートレット・プリファレンスを作成できます。これにより、ポートレットのユーザーは、実行時にポートレットの値を指定できるようになります。手順18に進みます。
このオプションを選択していない場合は、手順24に進みます。
「カスタマイズ・プリファレンス」ページで、「追加」をクリックして、新しいポートレット・プリファレンスをポートレットに追加します。
このウィザードは、デフォルトで、ユーザーがポートレット・タイトルをカスタマイズできるようにするポートレット・プリファレンスを組み込みます。
「新規プリファレンスの追加」ダイアログの「名前」フィールドに、新しいプリファレンスの名前を入力します。
この名前はポートレット内で一意である必要があり、空白を含めることはできません。
「デフォルト値」フィールドに、新しいプリファレンスの1つ以上のデフォルト値を入力します。複数の値は、カンマで区切ってください。
様々な言語でプリファレンスを使用できるようにする場合は、「プリファレンスの翻訳」チェック・ボックスを選択します。
たとえば、ポートレットが多言語ポータルで利用される可能性がある場合は、適切な言語でプリファレンスを表示する必要があります。
このオプションを有効にすると、プリファレンスのエントリは、そのポートレット用にJDeveloperが生成するリソース・バンドル・クラスに追加されます。
ヒント:
このリソース・バンドルを編集して、プリファレンスの名前とデフォルト値の翻訳を指定します。ほとんどの場合、名前の翻訳は必要になりますが、デフォルト値の翻訳が必要になることはありません(その値が整数の場合など)。
「OK」をクリックします。
さらに別のプリファレンスを追加する場合は、前の手順を繰り返します。完了したら、「次へ」をクリックします。
「セキュリティ・ロール」ページで、既存のセキュリティ・ロールをポートレットに追加するには、セキュリティ・ロールを選択して、「選択済」リストに移動します。
セキュリティ・ロールを使用すると、ポートレットに階層レベルのアクセスを設定できます。たとえば、「表示」ユーザーはポートレットを表示できますが編集はできません。「カスタマイズ」ユーザーは、ポートレットをカスタマイズできます。「管理」ユーザーは、ポートレット関連の使用可能なすべての機能を実行できます。
「使用可能」リストには、ポートレットを作成するアプリケーションに定義されたセキュリティ・ロールが表示されます。セキュリティ・ロールを「選択済」リストに移動することで、アプリケーションのポートレット・デプロイメント・ファイル(portlet.xml)にセキュリティ・ロールの参照を作成します。この参照は、アプリケーションのWebデプロイメント・ファイル(web.xml)のセキュリティ・ロールを参照します。
アプリケーションの新しいセキュリティ・ロールは、web.xmlを編集することで作成できます。詳細は、JDeveloperのオンライン・ヘルプを参照してください。
「Next」をクリックします。
「キャッシュ・オプション」ページで、「キャッシュ・ポートレット」を選択して、ポータルの有効期限ベースのキャッシュを有効にします。
有効期限ベースのキャッシュの詳細は、「ポートレット・パフォーマンス」および「JSR 286ポートレットでの有効期限ベースのキャッシュの実装」を参照してください。
このオプションを選択すると、ポートレットのキャッシングをポートレット・コンテナで管理することを示されます。ポートレット自体で、指定のレスポンスのコンテンツをキャッシュすることもできます。このページで指定する設定は、レスポンスに対するキャッシュ条件がポートレットで指定されていない場合にのみ適用されます。
このポートレットにデフォルト・キャッシュが必要ない場合は、「デフォルトでキャッシュしない」を選択します。この場合、ウィザードではキャッシュ有効期限が0秒に設定されます。前述したとおり、このキャッシュ設定が有効となるのは、レスポンスに対するキャッシュ条件がポートレットで指定されていない場合のみです。
ここでキャッシュしない設定を選択していても、ポートレットのデフォルト・キャッシュは後から実装できます。デフォルト・キャッシュを実装する場合は、このウィザードで生成したportlet.xmlファイルで、キャッシュ有効期限の値を0より大きい数値に変更します。
検証ベースのキャッシュを実装する方法の詳細は、「JSR 286ポートレットでの検証ベースのキャッシュの実装」を参照してください。
ポートレットをキャッシュすることにした場合、「デフォルト失効条件」セクションで、次のオプションを選択します。
キャッシュ・コンテンツ有効期限(秒): キャッシュされたポートレット・コンテンツを、一定の時間が経つと期限切れになるようにする場合。対応するフィールドに、制限時間を指定します。
「キャッシュ・コンテンツ無期限」: キャッシュされたポートレット・コンテンツに有効期限を設定しません。ポートレットのコンテンツが静的であまり変化しない場合は、このオプションを選択します。
「Next」をクリックします。
「初期化パラメータ」ページでは、ポートレットの初期化パラメータを追加できます。
WARファイルの内容を決定するアプリケーション開発者は、アプリケーションの各種コンポーネント(サーブレットやポートレットなど)のすべての動作を構成するためのJNDI変数のかわりに、互換性のある方法で初期化パラメータを使用できます。初期化パラメータは、portlet.xmlファイルに追加されます。
たとえば、ポートレットに対してなんらかのデバッグ・モードをオンにしたり、環境に応じて異なるメニュー・オプションを表示することが必要になる場合があります。
「新規」をクリックして、新しい初期化パラメータをポートレットに追加します。
新しく追加された行で、各フィールドをダブルクリックして、そのパラメータの「名前」、デフォルトの「値」、および「説明」を指定します。
ここに示した手順を繰り返して、さらに初期化パラメータを追加します。
完了したら、「終了」をクリックしてポートレットを作成します。
JSR 286 Javaポートレットの作成ウィザードを使用すると、ポートレットのデフォルトの実装がJDeveloperで生成されます。具体的には、次のファイルが作成されます。
Javaクラス:
portletName.javaは、ポートレット・コンテナから呼び出されます。このクラスには、ポートレット標準に必要なすべてのメソッドが含まれています。
portletNameBundle.javaには、ポートレットのすべての翻訳文字列が含まれています。
portletNameBacking.javaには、ポートレット・モードを実装するJSFページのJSFバッキングBeanが含まれています。このクラスは、ポートレット・モードをADF-Facelets JSPページとして実装した場合に作成されます。
portlet.xmlは、アプリケーション用のポートレット・デプロイメント・ディスクリプタ・ファイルです。
web.xml: アプリケーションのWebデプロイメント・ディスクリプタ・ファイルです。
ポートレットに選択した各ポートレット・モード用のファイル:
ポートレット・モードに「JSPの生成」を選択した場合は、そのモードに応じたJSPページ(たとえば、view.jsp.)が作成されます。
「ADF-Faces JSPXの生成」を選択した場合は、そのモードに応じたJSF (.jspx)ページ(view.jspxなど)が作成されます。このページには、Facesコンポーネントを追加できます。
「パスへのマップ」を選択した場合は、追加のファイルは作成されません。ポートレット・モードに応じたコードは、既存のリソース内にあります。ポートレットのJavaクラスにコードが追加され、指定したターゲットにリクエストがルーティングされるようになります。
「カスタム・コード」選択した場合は、追加のファイルは作成されません。ただし、ポートレット・モードに応じたコードは、ポートレットのJavaクラス内にあります。
faces-config.xmlは、カスタム・バリデータやマネージドBeanといったアプリケーションのリソースを登録したり、アプリケーションのページ・フローを示す構成ファイルです。このファイルは、ポートレット・モードをADF-Facelets JSFページとして実装した場合に作成されます。
ファイルはすべて、図13-3に示すようにアプリケーション・ナビゲータで確認できます。
JSR 286 Javaポートレットの作成ウィザードを使用してポートレットの初期実装を作成したときには、その次の段階でポートレット・コンテンツと動作を制御するコードを作成します。JSR 286ポートレットはJava標準に準拠しているため、このポートレットの拡張に関する十分な情報が、サード・パーティの書籍やWebページなどの各種情報源から入手できます。
http://jcp.org/en/jsr/detail?id=286
この項には次のトピックが含まれます:
次に、ポートレット・デプロイメント・ディスクリプタ・ファイルの例を示します。
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <portlet-app version="2.0" xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd" xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <portlet id="1328624289503"> <portlet-name>myPortlet</portlet-name> <display-name xml:lang="en-US">Portlet1</display-name> <display-name xml:lang="en">English Display Name</display-name> <portlet-class>portlet.Portlet1</portlet-class> <expiration-cache>300</expiration-cache> <supports> <mime-type>text/html</mime-type> <portlet-mode>edit</portlet-mode> </supports> <supported-locale>en-US</supported-locale> <resource-bundle>portlet.resource.Portlet1Bundle</resource-bundle> <portlet-info> <title>This Is My Portlet</title> <short-title>My Portlet</short-title> <keywords/> </portlet-info> <portlet-preferences> <preference> <name>portletTitle</name> </preference> </portlet-preferences> </portlet> <custom-portlet-mode> <portlet-mode>about</portlet-mode> </custom-portlet-mode> <custom-portlet-mode> <portlet-mode>config</portlet-mode> </custom-portlet-mode> <custom-portlet-mode> <portlet-mode>edit_defaults</portlet-mode> </custom-portlet-mode> <custom-portlet-mode> <portlet-mode>preview</portlet-mode> </custom-portlet-mode> <custom-portlet-mode> <portlet-mode>print</portlet-mode> </custom-portlet-mode> </portlet-app>
アプリケーション用のポートレット・デプロイメント・ディスクリプタ・ファイルportlet.xmlでは、アプリケーション内でのポートレット・リソースを指定します。ウィザードを使用してJSR 286ポートレットの作成を完了したら、portlet.xmlファイルを編集することでポートレット・リソースを編集します。
JDeveloperでportlet.xmlファイルを開くと、ソース・コードを編集したり、「ソース」ビューでこのファイルを手動で変更しなくても、概要エディタを使用してポートレット・リソースを編集できます。
ポートレット・デプロイメント・ディスクリプタ・ファイルを編集するには:
JSR 286でサポートされている標準モードは、次のとおりです。
表示
編集
ヘルプ
WebCenter Portalは、JSR 286ポートレットで次の追加カスタム・モードをサポートしています。
情報
構成
デフォルト編集
プレビュー
印刷
JSR 286 Javaポートレットの作成ウィザードでポートレット・モードを追加するには、「コンテンツ・タイプとポートレット・モード」ページのリストにポートレット・モードを追加します。ウィザードの使用方法の詳細は、「JSR 286 Javaポートレットの作成」を参照してください。このウィザードを使用すると、JSR 286でサポートされている標準モードと、WebCenter Portalでサポートされている拡張モードを実装できます。
ポートレットの初期作成後に、独自のカスタム・ポートレット・モードを定義することもできます。
ポートレット・モードの基本的な実装方法は、すべてのモードに共通しています。
カスタム・ポートレット・モードを追加するには:
ポートレット・プロデューサ・アプリケーションにユーザー属性を作成することで、一般的なユーザー情報(user.login.idやuser.name.familyなど)にアクセスできるようになります。これらのユーザー属性は、実行時に、現在のユーザーの実際の属性にマップされます。ポートレットでは、この情報を使用して、現在のユーザーについての情報を取得します。
ユーザー情報にアクセスするには:
ポートレットの実行時には、ポートレット・コンテナがランタイム環境を提供します。さらに、ポートレット・プロデューサ・アプリケーションとポートレットとの間のインタフェースも提供します。
コンテナ・ランタイム・オプションを使用すると、ポートレット・コンテナの動作をカスタマイズできます。このオプションで、ランタイム環境をカスタマイズします。
この項には次のトピックが含まれます:
表13-1に、WebCenter Portalポートレット・コンテナでサポートされるコンテナ・ランタイム・オプションを示します。
JSR 286のコンテナ・ランタイム・オプションの詳細は、次の場所にあるJSR 286の仕様を参照してください。
表13-1 サポートされるコンテナ・ランタイム・オプション
| コンテナ・ランタイム・オプション | サポート元 | JSR 286標準 |
|---|---|---|
アプリケーション ポートレット |
はい |
|
アプリケーション ポートレット |
はい |
|
java.portlet.renderHeaders |
サポート対象外 |
はい |
アプリケーション ポートレット |
はい |
|
アプリケーション |
いいえ |
|
アプリケーション |
いいえ |
|
アプリケーション ポートレット |
いいえ |
|
com.oracle.portlet.defaultProxiedResourceRequiresWsrpRewrite |
アプリケーション ポートレット |
いいえ |
アプリケーション ポートレット |
いいえ |
|
アプリケーション ポートレット |
いいえ |
|
アプリケーション ポートレット |
いいえ |
|
アプリケーション |
いいえ |
|
アプリケーション ポートレット |
いいえ |
|
アプリケーション ポートレット |
いいえ |
|
アプリケーション ポートレット |
いいえ |
|
アプリケーション ポートレット |
いいえ |
|
アプリケーション ポートレット |
いいえ |
|
アプリケーション ポートレット |
いいえ |
|
アプリケーション ポートレット |
いいえ |
|
com.oracle.portlet.renderHeaders |
アプリケーション ポートレット |
いいえ |
アプリケーション ポートレット |
いいえ |
|
アプリケーション ポートレット |
いいえ |
|
アプリケーション ポートレット |
いいえ |
|
アプリケーション ポートレット |
いいえ |
|
アプリケーション ポートレット |
いいえ |
|
アプリケーション |
いいえ |
|
アプリケーション ポートレット |
いいえ |
|
ポートレット |
いいえ |
|
ポートレット |
いいえ |
|
ポートレット |
いいえ |
アクション・スコープ指定型リクエスト属性を保存して、新しいアクションが発生するまで、その属性を使用できるようにするかどうかを指定します。
WebCenter Portal固有のexcludedActionScopeRequestAttributesコンテナ・ランタイム・オプションを使用すると、スコープで保存するリクエスト属性を制限できます。
有効な値は、次のとおりです。
true - リクエスト属性をprocessActionから、その次のprocessActionまで保存します。numberOfCachedScopesの2番目の値と、ポートレット・コンテナによりキャッシュされるスコープの数を示す3番目の値を指定できます。
false - リクエスト属性を保存しません。
JSR 286タグ・ライブラリのタグactionUrl、renderUrl、およびresourceUrlから返されたURLをXMLエンコードするかどうかを指定します。
このオプションは、encodeXml属性を使用することで、タグごとにオーバーライドできます。
有効な値は、次のとおりです。
true - (デフォルト) actionUrlタグ、renderUrlタグ、およびresourceUrlタグで返されたURLがXMLエンコードされます(パラメータの区切りには、アンパサンドのエンティティが使用されます)。
false - actionUrlタグ、renderUrlタグ、およびresourceUrlタグから返されたURLは、XMLエンコードされません(また、アンパサンド文字は、そのまま使用されます)。
注意:
このオプションは、PortletURL.toString()またはResourceURL.toString()の戻り値には一切影響しません。どちらの場合も、JSR 286では、出力にアンパサンド文字のみを使用します。生成するURLがタグ・ライブラリを使用しないときに、アンパサンド・エンティティを使用する場合や、使用するXMLエンコーディングを指定する場合は、BaseURL.write()メソッドを参照してください。
Javaポートレットに含まれている、またはJavaポートレットから転送されるサーブレットまたはJSPに提供するセッション・オブジェクトのスコープを指定します。
有効な値は、次のとおりです。
APPLICATION_SCOPE - (デフォルト)ポートレット・セッションをアプリケーション・スコープにマップします。
PORTLET_SCOPE - ポートレット・セッションをポートレット・スコープにマップします。
portlet.xmlで宣言されたイベント・ペイロードのタイプと、JSR 286ポートレットから送信されるイベント・ペイロードが、JSR 286の仕様(これらのタイプには、有効なJAXBバインディングが必要という要件)をバイパスできるようにします。
有効な値は、次のとおりです。
true - 有効なJAXBバインディングがないイベント・ペイロードが許可されます。
false - 有効なJAXBバインディングがないイベント・ペイロードは許可されず、JSR 286仕様に従います。
Webアプリケーションに対してWSRPのexport-portlets操作をサポートするべきかどうかを指定します。
このオプションは主に後方互換性のために使用されます。export-portlets操作はwsrp-producer-config.xml設定を使用して制御することをお薦めします。
有効な値は、次のとおりです。
true - (デフォルト)ポートレットのエクスポートが許可されます。
false - ポートレットのエクスポートは許可されません。これにより、WEB-INF/wsrp-producer-config.xmlの設定がオーバーライドされます。
owc168に設定すると、WebCenter PortalのJSR 286コンテナをJSR 168互換モードで呼び出します。
さらに、disallowResourceServingランタイム・オプションが、自動的にtrueに設定されます(別の値が指定されていない場合)。
ポートレットが提供しないリソースのURLエンコードするときに使用する、デフォルトのWSRP requiresRewriteフラグを指定します。PortletResponse.encodeURL()メソッドの呼出し時にoracle.portlet.server.resourceRequiresRewritingリクエスト属性でオーバーライドしないかぎり、この設定はPortletResponse.encodeURL()メソッドで戻されたすべてのURLに使用されます。
有効な値は、次のとおりです。
true - (デフォルト) requiresRewriteフラグにtrueが設定されます。これは、コンシューマがリソースを書き換える必要があることを示します。
false - requiresRewriteフラグがfalseに設定されます。これは、コンシューマがリソースを必ずしも書き換える必要がないことを示します。
ポートレットが提供するリソースのリソースURLを生成するときに使用する、デフォルトのWSRP requiresRewriteフラグを指定します。
この設定はポートレットで作成されたすべてのリソースURLに使用されます。ただし、リソースURLのメソッドwrite()またはtoString()の呼出し時にresourceRequiresRewritingリクエスト属性の有無でオーバーライドされます。この設定は、提供されたリソースのレスポンスにWSRP requiresRewritingフラグを指定するためにも使用されます。ただし、ポートレットのserveResource()メソッドの復帰時にresourceRequiresRewritingリクエスト属性の有無でオーバーライドされることがあります。
有効な値は、次のとおりです。
true - requiresRewrite URLフラグおよびrequiresRewritingレスポンス・フラグがtrueに設定されます。これは、コンシューマがリソースを書き換える必要があることを示します。
false - requiresRewrite URLフラグおよびrequiresRewritingレスポンス・フラグがfalseに設定されます。これは、コンシューマがリソースを必ずしも書き込む必要がないことを示します。ただし、コンシューマがURLを書き換える可能性はあります。
これを指定していない場合、requiresRewrite URLフラグに値が指定されなくなり、serveResource操作のrequiresRewritingレスポンス・フラグはレスポンスのMIMEタイプに基づいて設定されます。
ポートレットによるリソースの提供を許可するかどうかを指定します。これは、JSR 168ポートレットを286コンテナで実行する場合に役立ちます。javax.portlet.GenericPortletを拡張しているJSR 168ポートレットは、自動的にJSR 286の機能を継承するため、リソースIDに関連する名前の付いたWebアプリケーション内のファイルにリソース・リクエストを自動的に転送します。このことが、潜在的なセキュリティ問題になります。同様のセキュリティ上の理由から、リソースを提供しないJSR 286ポートレットは、リソースの提供を禁止することで最も安全になります。
有効な値は、次のとおりです。
true - ポートレットにリソースの提供を許可しません。
false - ポートレットにリソースの提供を許可します。
JSR 286コンテナのPortletResponse.encodeURL()メソッドで生成されるURLを、XMLエンコードするかどうかを指定します。
有効な値は、次のとおりです。
true - PortletResponse.encodeURL()メソッドで生成されるURLは、XMLエンコードされます。
false - (デフォルト) PortletResponse.encodeURL()メソッドで生成されるURLは、XMLエンコードされません。
イベントがWSRPを通じて送信されたされたときに、JAXBバインディング可能なJavaオブジェクトのイベント・ペイロードに対して、オプションのXMLスキーマ・タイプを指定します。これは、複数値のランタイム・オプションです。各値は、Javaクラス名とQNameのペアで構成し、コロン(:)で区切ります。QNameには、QNameの標準Java文字列表現({namespace}localpart)を使用する必要があります。指定した各値に対して、XMLスキーマ・タイプとしてQNameが使用され、オブジェクトがXMLにマーシャリングされた後で、指定したJavaオブジェクト・タイプのWSRPイベント・ペイロードに注釈を付けます。これは、複数のプロデューサにあるポートレット間で通信するイベントを使用するときに役立ちます。
これは、各値が正規表現の複数値プロパティです。com.oracle.portlet.externalScopeRequestAttributesコンテナ・ランタイム・オプションに定義された正規表現と一致する値を含むリクエスト・パラメータに加えて、正規表現と一致するリクエスト属性は、javax.portlet.actionScopedRequestAttributesコンテナ・ランタイム・オプションが使用されている場合、アクション・スコープ指定リクエスト属性としては保存されません。
これは、各値が正規表現の複数値プロパティです。正規表現のいずれかと一致するリクエスト属性は、ポートレット・スコープの外側にあるとみなされ、その基になるポータル・リクエストで共有されます。
javax.portlet.actionScopedRequestAttributesオプションを使用すると、externalScopeRequestAttributesで宣言された正規表現と一致するリクエスト属性は、アクション・スコープのリクエスト属性に保存されなくなります。
ポータル・コンシューマに対して、IFRAMEポートレットにCSSファイルをインポートする必要があるかどうかを指定します。
有効な値は、次のとおりです。
false: (デフォルト)何も実行されません。
true: コンシューマからのCSSファイルがIFRAMEポートレットに適用されます。
ポートレットの動作に必要なWSRPの最小バージョンを指定します。指定した値よりも小さいWSRPバージョンが使用されている場合、WSRP GetServiceDescription、GetPortletDescription、GetMarkupなどのWSRPレスポンスにポートレットが含まれなくなります。
有効な値は、次のとおりです。
1
2
WSRPプロデューサのサービスの説明にポートレットを提示するかどうかを指定します。
JSR 168/286ポートレットを参照する.portletファイルのofferRemote設定は、このコンテナ・ランタイム・オプションをオーバライドします。
有効な値は、次のとおりです。
true - (デフォルト)ポートレットは、WSRPプロデューサのサービスの説明に提示されます。
false - ポートレットは、サービスの説明に含まれません。
すべての指定を省略すると、WEB-INF/producer-config.xmlで指定されたデフォルト値が使用されます。
com.bea.portlet.container.IPortalInfoインタフェースのオプション実装のクラス名を指定します。この実装では、JSR 286コンテナのrequest.getPortalContext().getPortalInfo()から返される値を定義します。デフォルトの実装は、プロデューサ/ローカル・サーバーの名前とバージョンを返しますが、カスタムの実装はWSRPシナリオでコンシューマ・サーバー情報とプロデューサ・サーバー情報の両方を渡すことがあります
JSR 286コンテナは、processActionが実行された後で(また、イベントが処理された後で)、ブラウザにポータルのレンダラURLへのリダイレクトを送信して、結果のページをリロードしても別のprocessActionにならないようにします。
有効な値は、次のとおりです。
true - ポートレット・アクションの終了ごとに、リダイレクトが発行されます。
false - ポートレット・アクションの後に、リダイレクトが自動的には発行されません。
IFRAME内でポートレットをレンダリングする必要があるかどうかを指定します。
有効な値は、次のとおりです。
true - ポートレットをIFRAME内でレンダリングします。
false - ポートレットをIFRAME内でレンダリングすることを強制しません。
ポートレットがストリーミング・モードでの実行に最適化されていることを示します。これにより、パフォーマンスが向上することがあります。
有効な値は、次のとおりです。
true - ストリーミング・モードでの実行に向けてポートレットが最適化されています。
false - ストリーミング・モードでの実行に向けてポートレットは最適化されていません。
ポートレットがWSRPで実行されている場合、アクションとイベント(または、そのどちらか)のライフサイクル終了後に、ポートレットのオプティミスティック・レンダリングを抑制します。
有効な値は、次のとおりです。
true - オプティミスティック・レンダリングが常に抑制されます。
false - オプティミスティック・レンダリングが実行される場合があります。
レンダリング時にJSR 286コンテナがWSRP SOAP障害として例外を送信する必要があるのか、そのかわりにポートレット・マークアップの例外メッセージをレンダリングする必要があるのかを指定します。
有効な値は、次のとおりです。
true - 例外はSOAPフォルトとして送信されず、かわりにレンダリングされた例外スタック・トレースとして送信されます。
false - (デフォルト)レンダリング中にポートレットによって生成された例外はSOAPフォルトとして処理されます。
JSR 286コンテナでPortletResponse.encodeURL()メソッドに渡すURLから空白をトリミングする必要があるかどうかを指定します。
有効な値は、次のとおりです。
true - (デフォルト) PortletResponse.encodeURL()に渡されるURLから先頭と末尾の空白がトリミングされます。
false - PortletResponse.encodeURL()に渡されるURLから空白はトリミングされません。
PortletRequestのメソッドgetRemoteUser()、getUserPrincipal()およびisUserInRole()がWSRPユーザー・コンテキスト情報と標準J2EEセキュリティのどちらに基づくかを指定します。
有効な値は、次のとおりです。
true - ポートレットがWSRPで実行される場合、ユーザー情報はWSRPユーザー・コンテキストに基づきます。これはセキュリティ上の問題になることがあるため、このオプションの使用には十分な注意が必要です。
false - (または、ポートレットがWSRPで実行されていない場合)ユーザー情報は、J2EE認証済ユーザーに基づきます。
ポートレットがWSRPリモート・ポートレットとしてレンダリングされている場合にのみ使用します。ヘッダーまたはCookieの目的の最終宛先についてのWSRPコンシューマへのヒントとして、CookieとヘッダーがWSRP SOAPレスポンスのどこに含まれているかを示します。
ポートレットがローカルに(WSRPを経由しないで)実行されている場合、ポートレットで設定するヘッダーとCookieは、常にクライアントに向けられていると仮定されます。このコンテナ・ランタイム・オプションを設定することで、PortletRequest属性のcom.oracle.portlet.wsrpHeaderModeにデフォルト値を設定することになります。この値は、実行時にヘッダーごとにポートレットによりオーバーライドされる可能性があります。
有効な値は、次のとおりです。
client - ポートレットで設定されたヘッダーとCookieは、クライアント(たとえば、ブラウザ)に向けてリダイレクトされます。
consumer - ポートレットで設定されるヘッダーとCookieは、コンシューマに向けてリダイレクトされ、クライアントには渡されません。
both - ポートレットで設定されるヘッダーとCookieは、クライアントとコンシューマに向けてリダイレクトされます。
設定されていない場合、ポートレット・コンテナは、WEB-INF/wsrp-producer-config.xmlファイルで指定されている、プロデューサのデフォルト値を仮定します。
レガシーWSRPポートレット・ハンドルの仕様をポートレットで使用できるようにします。このハンドルは、Webアプリケーション内で一意にする必要があります。これは、従来のポートレットの位置ベースのWSRPポートレット・ハンドルを使用するWebCenter Portalコンシューマとの後方互換性を維持するために役立ちます。
指定されていると、レガシー・ポートレット・ハンドルがポートレットのレガシー・ハンドル拡張としてWSRP serviceDescriptionで公開され、コンシューマはレガシー・ポートレット・ハンドルを使用してポートレットにアクセスできるようになります。ただし、そのポートレットが、レガシー・ポートレット・ハンドルでWSRP serviceDescriptionに公開されることはありません。
WSRPポートレット・ハンドルの仕様をポートレットで使用できるようにします。このハンドルは、Webアプリケーション内で一意にする必要があります。
コンテナ・ランタイム・オプションをアプリケーション・レベルで設定すると、その設定はアプリケーション内のすべてのポートレットに作用します。
アプリケーションレベルのコンテナ・ランタイム・オプションを設定するには:
この項には次のトピックが含まれます:
パブリック・レンダラ・パラメータを使用すると、複数のポートレットでパラメータ値を共有できるようになり、ポートレット間通信が可能になります。
たとえば、地図ポートレットと天気概況ポートレットが、どちらもZipcodeパブリック・レンダラ・パラメータを使用するように構成されていると、地図ポートレットに郵便番号を入力することで、天気概況ポートレットの同じパラメータの値も更新されます。
ポートレットでサポートされるパブリック・レンダラ・パラメータは、ポートレット・デプロイメント・ディスクリプタ・ファイル(portlet.xml)のアプリケーション・セクションで宣言する必要があります。このように、アプリケーション・レベルで定義したパブリック・レンダラ・パラメータは、アプリケーション内のすべてのポートレットで使用できるようになります。
その後で、アプリケーション内の個別のポートレットでは、それらのパブリック・レンダラ・パラメータから使用する必要のあるものを指定できます。
パブリック・レンダラ・パラメータを後述するように宣言して定義すると、自動的にポートレット間通信が始まります。そのためのコーディングは必要ありません。
パブリック・レンダラ・パラメータの詳細と実装方法は、次の場所にあるJSR 286の仕様を参照してください。
パブリック・レンダラ・パラメータをポートレットで使用できるようにするには、最初に、ポートレット・デプロイメント・ディスクリプタ・ファイル(portlet.xml)のアプリケーション・セクションで、このパラメータを宣言する必要があります。
アプリケーション・レベルでパブリック・レンダラ・パラメータを定義するには:
portlet.xmlファイルの概要エディタを開きます。
詳細は、「ポートレット・デプロイメント・ディスクリプタ・ファイルの編集方法」を参照してください。
「パラメータ」タブをクリックします。
「追加」アイコンをクリックして、新しいパブリック・レンダラ・パラメータを作成します。
ドロップダウン・リストから、パラメータに完全修飾名(QName)を指定するか、名前のローカル・パートのみを指定するかを選択します。
修飾名 - パラメータのネームスペースとローカル名を指定することで、QNameは、パブリック・レンダラ・パラメータをアプリケーション間で一意に特定します。ポートレット・コード内では、識別子でパブリック・レンダラ・パラメータにアクセスします。この識別子により、アプリケーション内でパラメータを一意に識別します。ただし、一般に、ページには複数のポートレットが収容されていて、それらが異なるアプリケーションから取得されている可能性があります。QNamesを使用することで、あるポートレットのパブリック・レンダラ・パラメータが、ページ上の別のポートレットに意図せず干渉することがなくなります。これらのポートレットの取得先は問題になりません。
未修飾名 - パラメータのネームスペースが、アプリケーションのデフォルト・ネームスペースと同じ場合は、パラメータの定義時に未修飾名を指定することで、ネームスペースを省略できます。アプリケーションのデフォルト・ネームスペースが定義されていない場合、未修飾名のパラメータにはXMLのデフォルト・ネームスペースが使用されます。
ヒント:
アプリケーションのデフォルト・ネームスペースが定義されているかどうかを確認するには、「アプリケーション」タブをクリックして、「デフォルト・ネームスペース」フィールドに値が入力されているかどうかを調べます。
パラメータの名前を入力します。
「修飾名」を選択した場合 - 「ネームスペース」フィールドにパラメータのネームスペースを入力し、「名前」フィールドにパラメータ名のローカル・パートを入力します。
「未修飾名」を選択した場合 - 「名前」フィールドに、パラメータ名のローカル・パートを入力します。このパラメータには、パラメータのネームスペースとしてアプリケーションのデフォルト・ネームスペースが使用されます(アプリケーションにデフォルト・ネームスペースが定義されていない場合は、XMLのデフォルト・ネームスペースが使用されます)。
「識別子」フィールドに、パブリック・レンダラ・パラメータをアプリケーション内で識別するための名前を入力します。
この識別子は、アプリケーション内で一意にする必要があります。また、この識別子は、ポートレットとポートレットのコード内でパラメータにアクセスする際に、パラメータを識別するために使用されます。識別子を使用することで、ポートレット開発者は、パラメータの完全修飾名を認識する必要がなくなります。完全修飾名よりも単純なアプリケーション固有の識別子を知っていればよいことになります。
「説明」フィールドに、パブリック・レンダラ・パラメータの説明を入力します。説明には、このパラメータをポートレットに使用する開発者が、その使用方法を判断できる情報を指定する必要があります。
(オプション)「別名」パネルでは、別名のリストを指定できます。これらの別名により、異なるQNameが付いていても別のパブリック・レンダラ・パラメータの値を受け取れるようになります。
「作成」アイコンをクリックして、パラメータの新しい別名を作成します。
「ネームスペース」フィールドに、この別名に使用するパラメータのネームスペースを入力します。
「名前」フィールドに、この別名に使用するパラメータのローカル・パートを入力します。
ヒント:
パブリック・レンダラ・パラメータの別名を作成するときには、相互互換の別名を設定するようにしてください。つまり、ポートレットAのパラメータがポートレットBのパラメータに対応する別名を持つ場合は、可能であれば、ポートレットBのパラメータにもポートレットAのパラメータに対応する別名を作成するようにします。
パブリック・レンダラ・パラメータが、次に示すようにportlet.xmlファイルのアプリケーション定義セクションに追加されます。
<public-render-parameter> <description>Parameter for zip code</description> <identifier>Zip</identifier> <qname xmlns:x="http://example.com/params">x:Zip</qname> <alias xmlns:x="http://example.com/params">x:ZipCode</alias> </public-render-parameter>
portlet.xmlファイルを保存します。
あるポートレットでパブリック・レンダラ・パラメータをサポートする必要がある場合は、そのポートレットにパラメータを追加します。
ポートレットにパブリック・レンダラ・パラメータを追加するには:
次の例では、パブリック・レンダラ・パラメータを使用して、異なる名前のパラメータを使用している2つのポートレットの動作をリンクする方法を示しています。この例では、パブリック・レンダラ・パラメータの更新を可能にする汎用パラメータ・フォーム・ポートレットを取り上げて、どのようにして株価をレンダリングする株価ポートレットにそれをリンクして、パブリック・レンダラ・パラメータから株式記号を取得できるかを示します。パラメータ・フォーム・ポートレットのパラメータの一般名(parameter1)は、株価ポートレットのパラメータ名(stocksymbol)と一致しないため、株価ポートレットの開発者は、この2つのパラメータ間をリンクする別名を使用することになります。
次の例は、パラメータ・フォーム・ポートレットを含むポートレット・プロデューサ・アプリケーションのportlet.xmlファイルの抜粋部分を示しています。ポートレット・プロデューサ・アプリケーションでは、パラメータ・フォーム・ポートレットでサポートするパブリック・レンダラ・パラメータ(parameter1)を定義します。
<portlet-app ...> <portlet id="1234567890"> ... <supported-public-render-parameter> parameter1 </supported-public-render-parameter> ... </portlet> ... <public-render-parameter> <description xml:lang="en">First parameter set by portlet</description> <identifier>parameter1</identifier> <qname xmlns:op="http://xmlns.oracle.com/portlet/oracle-portlet-app"> op:parameter1 </qname> </public-render-parameter> ... </portlet-app>
パラメータ・フォーム・ポートレットのコードでは、このポートレットに値が入力されたときに、parameter1ポートレットの値を設定します。
public void processAction(ActionRequest request,
ActionResponse actionResponse)
throws PortletException, IOException
{
//
//Read the new parameter value posted in the portlet form
//
String param1 =actionResponse.getParameter("form_param1");
//
//Set the new parameter values. These will be intepreted by the
//container as public render parameters as the names match the names
//of the declared parameters.
//
actionResponse.setRenderParameter("parameter1", param1);
}
次の例は、株価ポートレットを含むポートレット・プロデューサ・アプリケーションのportlet.xmlファイルの抜粋部分を示しています。このポートレット・プロデューサ・アプリケーションでは、株価ポートレットでサポートされているパブリック・レンダラ・パラメータ(stocksymbol)も定義しています。パラメータ・フォーム・ポートレットのパラメータとリンクするように、stocksymbolパラメータに、parameter1という別名を追加します。
<portlet-app ...> <portlet> ... <supported-public-render-parameter> stocksymbol </supported-public-render-parameter> ... </portlet> ... <public-render-parameter> <description xml:lang="en">The stock symbol</description> <identifier>stocksymbol</identifier> <qname xmlns:s="http://www.oracle.com/stocks">s:stocksymbol</qname> <!-- Alias matches the Parameter Form portlet's first parameter name --> <alias xmlns:op="http://xmlns.oracle.com/portlet/oracle-portlet-app"> op:parameter1 </alias> </public-render-parameter> ... </portlet-app>
株価ポートレットのコードでは、パラメータ・フォーム・ポートレットでポストされたパブリック・レンダラ・パラメータの値を読み取ります。
public void doView(RenderRequest request, RenderResponse response)
throws PortletException, IOException
{
response.setContentType("text/html; charset=UTF-8");
PrintWriter out =response.getWriter();
//Retrieve any values for the public render parameter.
//The parameter is looked up in the request using its identifier in portlet.xml
//(not it's name or alias).
String symbol =request.getParameter("stocksymbol");
...
}
これらの2つのポートレットが同じページにドロップされると、相互に自動的にリンクされます。パラメータ・フォーム・ポートレットの最初のパラメータ・フィールドに値を入力すると、その新しい値で株価ポートレットが更新されるようになります。
この項には次のトピックが含まれます:
ポートレット・イベントとは、ポートレットの外部で行われたアクション(たとえば、そのポートレットを含むページで実行されたアクションや同じページ上の別のポートレットで実行されたアクション)に反応できるようにすることで、ポートレットのポートレット間通信を可能にするJSR 286の機能です。ポートレット・イベントは、ポートレットがそれ自体のイベントをトリガーすることでイベントに応答し、それがそのページ上の他のポートレットに影響を与えるようにカスケードできます。
ポートレットでサポートするポートレット・イベントは、ポートレット・デプロイメント・ディスクリプタ・ファイル(portlet.xml)のアプリケーション・セクションで宣言する必要があります。このように、アプリケーション・レベルで定義したポートレット・イベントは、アプリケーション内のすべてのポートレットで使用できるようになります。
その後で、アプリケーション内の個別のポートレットで、それらのポートレット・イベントから使用する必要のあるものを指定できます。ポートレットでは、受信を目的とする処理イベントというイベントと、ポートレットがトリガーする公開イベントというイベントを宣言できます。
ポートレット・イベントを後述するように宣言して定義すると、自動的にポートレット間通信が始まります。そのためのコーディングは必要ありません。
ポートレット・イベントの詳細と実装方法は、次の場所にあるJSR 286の仕様を参照してください。
ポートレット・イベントをポートレットで使用できるようにするには、最初に、ポートレット・デプロイメント・ディスクリプタ・ファイル(portlet.xml)のアプリケーション・セクションで、ポートレット・イベントを宣言する必要があります。
アプリケーション・レベルでポートレット・イベントを定義するには:
portlet.xmlファイルの概要エディタを開きます。
詳細は、「ポートレット・デプロイメント・ディスクリプタ・ファイルの編集方法」を参照してください。
「イベント」タブをクリックします。
「追加」アイコンをクリックして、新しいポートレット・イベントを作成します。
ドロップダウン・リストから、ポートレット・イベントに完全修飾名(QName)を指定するか、名前のローカル・パートのみを指定するかを選択します。
修飾名 - イベントのネームスペースとローカル名を指定することで、QNameは、ポートレット・イベントをアプリケーション間で一意に特定します。一般に、ページには複数のポートレットが収容されていて、それらが異なるアプリケーションに属していることがあります。QNamesを使用することで、あるポートレットのポートレット・イベントが、ページ上の別のポートレットに意図せず干渉することがなくなります。これらのポートレットの取得先は問題になりません。
未修飾名 - ポートレット・イベントのネームスペースが、アプリケーションのデフォルト・ネームスペースと同じ場合は、このイベントの定義時に未修飾名を指定することで、ネームスペースを省略できます。アプリケーションのデフォルト・ネームスペースが定義されていない場合、未修飾名のポートレット・イベントにはXMLのデフォルト・ネームスペースが使用されます。
ヒント:
アプリケーションのデフォルト・ネームスペースが定義されているかどうかを確認するには、「アプリケーション」タブをクリックして、「デフォルト・ネームスペース」フィールドに値が入力されているかどうかを調べます。
ポートレット・イベントの名前を入力します。
「修飾名」を選択した場合 - 「ネームスペース」フィールドにポータル・イベントのネームスペースを入力し、「名前」フィールドにイベント名のローカル・パートを入力します。
「未修飾名」を選択した場合 - 「名前」フィールドに、ポータル・イベント名のローカル・パートを入力します。このイベントには、イベントのネームスペースとしてアプリケーションのデフォルト・ネームスペースが使用されます(アプリケーションにデフォルト・ネームスペースが定義されていない場合は、XMLのデフォルト・ネームスペースが使用されます)。
「ペイロード・タイプ」フィールドに、ポートレット・イベントでサポートするペイロードのデータ・タイプを入力します。または、そのデータ・タイプを参照します。
「説明」フィールドに、ポートレット・イベントの説明を入力します。
(オプション)「別名」パネルでは、別名のリストを指定できます。これらの別名により、ポートレットで定義されたものと異なるQNameが付いていてもポートレット・イベントを認識できるようになります。
「作成」アイコンをクリックして、ポートレット・イベントの新しい別名を作成します。
「ネームスペース」フィールドに、この別名に使用するポートレット・イベントのネームスペースを入力します。
「名前」フィールドに、この別名に使用するポートレット・イベントのローカル・パートを入力します。
ポートレット・イベントが、次に示すようにportlet.xmlファイルのアプリケーション定義セクションに追加されます。
<event-definition id="latLong"> <qname xmlns:x="http://xmlns.oracle.com/portlet/EventSample"> x:latLong </qname> <value-type>portlet.LatLong</value-type> </event-definition>
portlet.xmlファイルを保存します。
あるポートレットで特定のポートレット・イベントをリスニングする必要がある場合、そのイベントは処理イベントとして定義します。
ポートレットに処理イベントを追加するには:
あるポートレットで特定のポートレット・イベントをトリガーする必要がある場合、そのイベントは公開イベントとして定義します。
ポートレットに公開イベントを追加するには:
次の例では、あるポートレットのアクションが同じページ上の別のポートレットに作用するために使用するポートレット・イベントの使用方法について説明しています。この例では、ある企業の様々なオフィスの地理的な場所を一覧表示する、部署の所在地ポートレットというポートレットを使用します。この例では、そのポートレットを別のポートレット(地図ポートレット)とリンクする方法を示します。地図ポートレットは、部署の所在地ポートレットで選択した場所のGoogleマップを表示します。
次の例は、2つのポートレットを含むポートレット・プロデューサ・アプリケーションのportlet.xmlファイルの抜粋部分を示しています。ポートレット・プロデューサ・アプリケーションでは、これら2つのポートレットでサポートするポートレット・イベント(latLong)を定義します。イベントのペイロードは、1つの場所の緯度と経度をカプセル化するオブジェクトです。
<event-definition id="latLong"> <qname xmlns:x="http://xmlns.oracle.com/portlet/EventSample">x:latLong</qname> <value-type>portlet.LatLong</value-type> </event-definition>
次の例は、部門場所ポートレットでlatLongイベントを公開イベントとして使用していることを示しています。これは、特定の状況下でイベントを発生します。
<portlet id="locations"> ... <supported-publishing-event> <qname xmlns:x="http://xmlns.oracle.com/portlet/EventSample">x:latLong<qname> </supported-publishing-event> ... </portlet>
部門場所ポートレットでは、このポートレット内で場所が選択されると、processActionメソッドでlatLongイベントが発生します(次の例を参照)。さらに、そのイベントのペイロードに、選択された場所の緯度と経度を設定します。
public void processAction(ActionRequest request, ActionResponse response)
throws PortletException
{
String locationId =request.getParameter("locationId");
Location location =getLocation(Integer.parseInt(locationId));
if (location != null)
{
//QName matches the event declared as a supported-publishing-event in
//portlet.xml for this portlet.
//LatLong event used by the Map portlet.
response.setEvent(new QName("http://xmlns.oracle.com/portlet/EventSample", "latLong"),
new LatLong(location.getLatitude(), location.getLongitude()));
}
}
次の例に、もう一方のポートレット(地図ポートレット)を示します。このポートレットもlatLongイベントを使用しますが、こちらは処理イベントとして使用します。そのため、イベントをリスニングして、ページ上の別の場所でイベントが発生したときには特定のアクションを実行することになります。
<portlet id="map"> ... <supported-processing-event id="latLong"> <qname xmlns:x="http://xmlns.oracle.com/portlet/EventSample">x:latLong</qname> </supported-processing-event> ... </portlet>
地図ポートレットのprocessEventメソッドは、latLongイベントを受信し、このイベントのペイロードを使用してLAT_LONG_PARAMETERレンダリング・パラメータを設定します。このパラメータは、レンダリング時にGoogleマップに表示する場所を決定するために、ポートレットで使用されます。
@Override
public void processEvent(EventRequest request,
EventResponse response)
throws PortletException, IOException
{
response.setRenderParameters(request);
Event event =request.getEvent();
if (event.getName().equals("latLong"))
{
response.setRenderParameter(LAT_LONG_PARAMETER, event.getValue().toString());
}
}
ヒント:
ここでは、部署の所在地ポートレットと地図ポートレットで使用されるイベントには同じ名前(latLong)が付けられています。地図ポートレットが別の名前(たとえば、geolocation)を使用してイベントをリスニングしている場合でも、次に示すように、portlet.xmlファイルでgeolocationイベントに別名を定義することで、これら2つのポートレットは自動的にリンクされるようになります。
<event-definition id="geolocation"> <qname xmlns:x="http://xmlns.oracle.com/portlet/Map"> x:geolocation </qname> <alias xmlns:x="http://xmlns.oracle.com/portlet/EventSample"> x:latLong </alias> <value-type>portlet.LatLong</value-type> </event-definition>
ただし、自動的なリンクが機能するには、この2つのイベントのペイロード・タイプを同じにする必要があることに注意してください。
注意:
ポートレット間でイベント・ペイロードを受け渡しするには、そのイベント・ペイロードからXMLペイロードに形式変換できる必要があります。これを可能にするには、次のいずれかの条件を満たしている必要があります。
ペイロードには、JAXBバインディングが必要です。たとえば、次に示すように、ポートレット・クラスにXmlRootElementアノテーションを追加します。
package portlet;
import java.io.Serializable;
import javax.xml.bind.annotation.XmlRootElement;
@XmlRootElement(namespace="http://xmlns.oracle.com/portlet/EventSample")
public class LatLong implements Serializable
{
private final double _latitude;
private final double _longitude;
...
allowEventPayloadsWithoutJAXBBindingsコンテナ・ランタイム・オプションは、portlet.xmlでtrueに設定する必要があります。
詳細は、「JSR 286ポートレット用のランタイム環境のカスタマイズ方法」を参照してください。
この項には次のトピックが含まれます:
ポートレット・プリファレンスを使用すると、エンド・ユーザーは、実行時にポートレットをパーソナライズまたはカスタマイズできるようになります。パーソナライズはこれらを実行するユーザーのみに表示され、他のユーザーには表示されません。カスタマイズは、ポートレットをパーソナライズしていないすべてのユーザーに表示されます。
デフォルトでは、JDeveloperのウィザードを使用してJSR 286ポートレットを作成すると、実行時にユーザーがポートレットのタイトルを変更できるようにポートレット・プリファレンスが作成されます。実行時にエンド・ユーザーがこれとは別の変更をポートレットに加えられるようにすために、追加のポートレット・プリファレンスを作成できます。追加のポートレット・リファレンスは、ポートレットの作成時に作成することも、ポートレットの作成後にportlet.xmlファイルを編集して作成することもできます。
ポートレットの作成後にポートレット・プリファレンスをportlet.xmlファイルに追加する方法の詳細は、「JSR 286ポートレットへのポートレット・プリファレンスの追加」を参照してください。ポートレットの作成時にポートレット・プリファレンスを追加する方法の詳細は、「JSR 286 Javaポートレットの作成」を参照してください。
ポートレットの動作またはコンテンツを、実行時にユーザーが変更できるようにするには、ユーザーが変更できるようにするポートレットの属性に応じたポートレット・プリファレンスを作成する必要があります。
ポートレット・プリファレンスをポートレットに追加するには:
この項には次のトピックが含まれます:
ポートレット・フィルタは、実行時にポートレットのコンテンツを変更できるようにするJSR 286の機能です。ポートレット・フィルタは、ポートレット・リクエストおよびポートレット・レスポンスのコンテンツを変換できる、再利用可能なJavaコンポーネントです。一般に、フィルタはポートレットのように応答を作成したり、リクエストに反応したりすることはありません。そのかわりに、リクエストおよびレスポンスを変更または変換します。
ポートレット・フィルタの詳細と実装方法は、次の場所にあるJSR 286の仕様を参照してください。
ポートレットでポートレット・フィルタを使用できるようにするには、最初に、そのフィルタをアプリケーション内で定義しておく必要があります。
ポートレット・フィルタをアプリケーションに追加するには:
portlet.xmlファイルの概要エディタを開きます。
詳細は、「ポートレット・デプロイメント・ディスクリプタ・ファイルの編集方法」を参照してください。
「Filters」タブをクリックします。
「追加」アイコンをクリックして、新しいポートレット・フィルタを作成します。
「ポートレット・フィルタの作成」ダイアログでは、新しいポートレット・フィルタを作成することも、以前に作成したポートレット・フィルタを選択することもできます。
新しいポートレット・フィルタを作成するには:
「新規ポートレット・フィルタ」を選択します。
「名前」フィールドに、ポートレット・フィルタの名前を入力します。
この名前はアプリケーション内で一意にする必要があります。また、文字、数字およびアンダースコアのみを使用する必要があります。
「パッケージ」フィールドに、新しいフィルタ・クラスを格納するパッケージを入力します。または、そのパッケージを参照します。
1つ以上の「ライフサイクル・フェーズ」チェック・ボックスを選択して、このフィルタ・クラスが実装するjavax.portlet.filterインタフェースを指定します。
アクション - このフィルタ・クラスはActionFilterインタフェースを実装します
イベント - このフィルタ・クラスは、EventFilterインタフェースを実装します。
レンダリング - このフィルタ・クラスは、RenderFilterインタフェースを実装します。
リソース - このフィルタ・クラスは、ResourceFilterインタフェースを実装します。
ヒント:
「ポートレット・フィルタの作成」ダイアログを使用して新しいフィルタ・クラスを作成するときには、そのフィルタ・クラスに実装するフィルタ・インタフェースを指定できます。フィルタ・クラス作成した後では、概要エディタ使用してフィルタ・インタフェースを追加または削除できなくなります。そのかわりに、フィルタ・クラスのソースを直接編集して、インタフェースと、そのインタフェースに定義されたdoFilterメソッドを手動で追加または削除することが必要になります。
既存のポートレット・フィルタを選択するには:
「既存のクラスから選択」を選択します。
フィルタ・クラスを入力または参照します。
「OK」をクリックします。
「表示名」フィールドに、ポートレット・フィルタのわかりやすい名前を入力します。
「説明」フィールドに、ポートレット・フィルタの説明を入力します。
「初期化パラメータ」パネルでは、フィルタ・クラスのinit()メソッドに値を渡すための初期化パラメータを指定できます。
「追加」アイコンをクリックして、ポートレット・フィルタの初期化パラメータを指定します。
「名前」フィールドに、初期化パラメータの名前を入力します。
「値」フィールドに、初期化パラメータに渡す値を入力します。
「説明」フィールドに、初期化パラメータの説明を入力します。
ポートレット・フィルタが、次に示すようにportlet.xmlファイルのアプリケーション定義セクションに追加されます。
<filter> <display-name>Test Filter</display-name> <filter-name>filter_1</filter-name> <filter-class>javaportlets.MyFilter</filter-class> <lifecycle>ACTION_PHASE</lifecycle> <lifecycle>RENDER_PHASE</lifecycle> </filter>
portlet.xmlファイルを保存します。
通常、ポートレット間通信は同じページに表示されているポートレット間で行われます。ただし、次の例で示すように別のページのポートレットとの間で通信することも可能です。
異なるページ間でのポートレット間通信の実装方法
ヒント:
単一の汎用eventHandlerを作成して、ページ・テンプレートに追加することもできます。ページ・テンプレートのメソッド・バインディングを追加することで、これはすべてのページで使用できるようになります。パブリッシャにワイルドカードを使用することで、特定の名前ですべてのイベントをリッスンできるようにします。
詳細およびサンプル・アプリケーションのダウンロードは、次のブログ・エントリを参照してください。
http://www.ateam-oracle.com/inter-portlet-communication-between-pages/
この項には次のトピックが含まれます:
ポートレットの基本機能の設定が完了した後は、ポートレットのパフォーマンスに注目する必要があります。
キャッシュは、高度な動的コンテンツを含むWebサイトのパフォーマンスの向上に使用される一般的な手法です。JSR 286ポートレットでは、有効期限ベースおよび有効化ベースのキャッシュがサポートされています。
キャッシュの詳細は、「ポートレット・パフォーマンス」を参照してください。
JSR 286ポートレットの作成ウィザードを使用して、最初にポートレットを作成するときには、有効期限ベースのキャッシュの実装を選択できます。ただし、ポートレットの初期デプロイメント時には、ポートレットのキャッシュをオフにして、デプロイメント・サイクルの後半でポートレット・コンテンツが安定してきたときに、このキャッシュを実装することが望まれることがあります。さらに、有効期間の編集や、キャッシュ・スコープの変更が必要になることもあります。
有効期限ベースのキャッシュを実装するには:
検証ベースのキャッシュの実装は、初期ポートレットの作成後に、手動でコーディングする必要があります。
次の例では、コンシューマが検証ベースのキャッシュを使用してマークアップをキャッシュするようにGenericPortletでdoView()メソッドを実装する場合の一般的な方法を示します。この例では、有効期限ベースのキャッシュをプログラム的に(CacheControl.setExpirationTime()メソッドを使用して)定義する方法と、検証ベースのキャッシュとの併用でプロデューサの負荷をさらに削減する方法についても示しています。これは、serveResource()の場合にも同様に機能します。
protected void doView (RenderRequest request, RenderResponse response)
throws PortletException, IOException
{
CacheControl cacheControl =response.getCacheControl();
String eTag =request.getETag();
if (isMarkupStillValid(eTag))
{
//Wait 30 seconds before checking ETag again
cacheControl.setExpirationTime(30);
//Tell consumer to use its cached content
cacheControl.setUseCachedContent(true);
return;
}
//ETag not valid so set a new one ...
//Define a new ETag
cacheControl.setETag(generateETag(...));
//Wait 60 seconds before checking ETag again
cacheControl.setExpirationTime(60);
//... and generate fresh portlet markup
createMarkup(request, response);
}
private boolean isMarkupStillValid(String eTag)
{
if (eTag ==null)
{
return false; //No ETag was supplied
}
//Perform portlet specific checks for the consumer's cached
//copy of the markup still being valid based on the given ETag
...
}
private String generateETag(...)
{
//Portlet specific code to generate an ETag, for example, a hash
//of the data on which the portlet's markup is based
...
return eTag;
}
JSR 286ポートレットの検証ベースのキャッシュの詳細は、次の場所にあるJSR 286の仕様を参照してください。
リソース・プロキシは、WSRPでリソースを取得する標準的な方法です。ポートレット内でのURLの問題を回避するには、指定したリソース内のURLをすべて書きなおすためのフラグを設定できます。たとえば、URLを含むHTMLのフラグメントがある場合、WSRPリソース・プロキシを考慮に入れてURLをリライトするために、このフラグを設定できます。
URLのリライトが必要なことを示すには、PortletRequest属性のoracle.portlet.server.resourceRequiresRewritingをtrueに設定します。たとえば、次のコードの抜粋部分のようなコードを含めると、エンコードするURLにリソース・プロキシが使用されるようになります。このコードはメソッド内にカプセル化して、このコードがURLごとに繰り返されないようにします。
request.setAttribute("oracle.portlet.server.resourceRequiresRewriting",
Boolean.TRUE);
String url =response.encodeURL(pathToResourceForRewriting);
request.removeAttribute("oracle.portlet.server.resourceRequiresRewriting");
oracle.portlet.server.resourceRequiresRewritingを具体的に設定していないと、falseにデフォルト設定され、URLはリライトされなくなります。この属性をtrueに設定することで、この機能を明示的にアクティブにする必要があります。
defaultProxiedResourceRequiresWsrpRewriteコンテナ・ランタイム・オプションを使用すると、デフォルトのWSRP requiresRewriteフラグを使用するように指定できます。このコンテナ・ランタイム・オプションで指定したオプション(デフォルトの設定はtrue)は、リクエスト属性でオーバーライドされていない場合に使用されます。詳細は、「com.oracle.portlet.defaultProxiedResourceRequiresWsrpRewrite」を参照してください。
リライトの必要がないプロトコル・リソースがある場合は、ステートレス・リソース・プロキシを使用できます。ステートレス・リソース・プロキシでは、ブラウザに返されるURLに、ポートレットIDなどのコンテキスト情報が必要なくなります。これにより、該当するリソースに対するキャッシュ・ヒット率が向上します。ステートレス・リソース・プロキシは、静的なJavaScriptファイルや静的なイメージなどの機能に有用なことがわかります。
ステートレス・プロキシが必要なことを示すには、PortletRequest属性のoracle.portlet.server.useStatelessProxyingをtrueに設定します。たとえば、次のコードの抜粋部分のようなコードを含めると、エンコードするURLにステートレス・プロキシが使用されるようになります。このコードはメソッド内にカプセル化して、このコードがURLごとに繰り返されないようにします。
request.setAttribute("oracle.portlet.server.useStatelessProxying", Boolean.TRUE);
String url =response.encodeURL(pathToResource);
request.removeAttribute("oracle.portlet.server.useStatelessProxying");
oracle.portlet.server.useStatelessProxyingを具体的に設定していないと、falseにデフォルト設定されます。この属性をtrueに設定することで、この機能を明示的にアクティブにする必要があります。
この項には次のトピックが含まれます:
ポートレット永続ストアは、コンシューマ登録ハンドルおよびポートレット・プリファレンス・データを永続的に保持するために使用されます。ポートレット・プロデューサは、3種類の永続ストアのうちの1つを使用できます。
Consumer - プロデューサのメタデータをコンシューマ・アプリケーションに関連付けます。このオプションをお薦めします。
Database - リレーショナル・データベースを使用してデータを永続化します。これは、主に後方互換性を維持することを目的としていますが、大量のカスタマイズが見込まれる場合には有効です。
File - ファイル・システムを使用してデータを永続化します。これは下位互換性の目的で提供されています。本番環境ではファイル・ベースの永続ストアは使用しないでください。この永続ストアでは、多層化環境や高可用性環境がサポートされません。ただし、ファイル・ベースの永続ストアを使用しながら、統合WLSを使用してアプリケーションをテストすることが必要になる場合があります。
詳細は、「ポートレットのパーソナライズとカスタマイズ」を参照してください。
表13-2に、WSRPプロデューサの永続ストアを指定するために使用するJNDI変数の一覧と説明を示します。
表13-2 WSRPプロデューサ・データベース・プリファレンス・ストア関連のJNDI変数
| 変数名 | 変数値 | 説明 |
|---|---|---|
|
|
ポートレット・プロデューサ・アプリケーションのコンシューマ登録ハンドルとポートレット・プリファレンスを永続化するために使用する、データ・ストア(ファイル、データベース、またはコンシューマ)を指定します。 |
|
|
ファイル・プリファレンス・ストアで使用されるルート・ディレクトリのパスを定義します。 絶対パスは、ファイル・システム・ルートを基準として解釈されます。相対パスは、 同じWebLogic Server内で実行されているすべてのプロデューサは、この変数に同じパスを使用する必要があります。このようにしていないと、一部のポートレットで |
WSRPポートレット・プロデューサでは、JNDI変数(persistentStore)を使用して、どのタイプの永続ストアを使用するかを判断します。アプリケーション内で最初のポートレットを作成するときには、この変数はデフォルトでConsumerに設定されています。この変数の値は、ポートレット・プロデューサ・アプリケーションのweb.xmlファイルで変更できます。
注意:
すでに別のポートレットが含まれているアプリケーションにポートレットを作成すると、既存の永続ストアの設定が維持されます。
ファイル永続ストアを使用する場合は、その永続ストアに使用するルート・ディレクトリへのパスを指定するために、JNDI変数のfileStoreRootも使用します。「WSRPプロデューサ永続ストア用のJNDI変数」を参照してください。
WSRPポートレット・プロデューサの永続ストアをセットアップするには:
たとえば、テスト環境から本番環境に移動するときに、ポートレット・プロデューサで使用する永続ストアのタイプを変更する必要がある場合は、既存のデータを元の永続ストアから新しい永続ストアに移行できます。
この項には次のトピックが含まれます:
WSRPポートレット・プロデューサの永続ストア移行ユーティリティ(PersistenceMigrationTool)を使用すると、データベース永続ストアとファイルベース永続ストアとの間で既存のデータを移行できます(たとえば、テストで使用していたファイルベース永続ストアから、本番環境のデータベース永続ストアへの移行)。また、このユーティリティを使用して、アップグレード中のユーザーは、既存のロケール固有のポートレット・プリファレンス・データが最新のJSPリリースと互換性のある名前形式を使用していることを確認できます。さらに、このユーティリティは、移行元と移行先のストアが同じタイプになる移行にも使用できるため、データベース間でのデータの移行も可能です。
注意:
PersistenceMigrationToolユーティリティを実行するときには、クラスパスで次のライブラリを参照する必要があります。
wcs-producer-spi.jar
portlet-utils.jar
portlet-producer-container-common.jar
portlet-producer-container-persistence.jar
oracle-portlet-api.jar
wsrp-container.jar
oracle-portlet-tags.jar
ojdbc6.jar
クラスパスで参照されるojdbc6.jarライブラリは、データベースで使用されるライブラリと同じにする必要があります。
データベースまたはファイルベースの永続ストアを移行するには:
次の例は、PersistenceMigrationToolユーティリティの実行を示しています。この例では、ファイル・ストアのプリファレンスがデータベース・ストアにコピーされます。
./java -classpath ORACLE_COMMON_HOME/modules/oracle.wccore/portlet-producer-container-persistence.jar: ORACLE_COMMON_HOME/modules/oracle.wccore/portlet-producer-container-common.jar: ORACLE_COMMON_HOME/modules/oracle.adf.share.ca/adf-share-base.jar: ORACLE_COMMON_HOME/modules/oracle.wccore/portlet-utils.jar: ORACLE_COMMON_HOME/modules/oracle.wccore/wcs-producer-spi.jar: ORACLE_COMMON_HOME/modules/oracle.adf.share/adflogginghandler.jar: DB_ORACLE_HOME/jdbc/lib/ojdbc6.jar oracle.portlet.server.containerimpl.PersistenceMigrationTool -sourceType file \ -sourcePath /data/prefs -destType db \ -destUsername scott \ -destPassword tiger \ -destDatabase abc.mycompany.com:1521:yourdatabase \
説明:
ORACLE_COMMON_HOMEは、Oracle共通ホームです
DB_ORACLE_HOMEは、データベースのOracleホームです(WebCenter Portal Oracleホームと同じマシン上にある場合)。データベースのOracleホームが別のマシンにある場合は、DB_ORACLE_HOME/jdbc/libディレクトリを、WebCenter Portal Oracleホームの一時ディレクトリにコピーします。クラスパスでは、この一時ディレクトリのojdbc6.jarライブラリを参照する必要があります。
コンシューマ永続ストア間の移行には、永続ストア移行ユーティリティを使用できません。コンシューマ永続ストア間の移行には、データをコンシューマのあるプロデューサからエクスポートして別のプロデューサにインポートする必要があります。
コンシューマ永続ストアを移行するには:
ポートレット・プロデューサを別のサーバーに移動したときには、そのプロデューサの永続ストアも移動する必要があります。
新しいプロデューサをインストールした後で、次に示すように永続ストアを移動します。
コンシューマ永続ストア - データはコンシューマに保存されるため、永続ストアを移動するための要件はありません。
データベース永続ストア: 次のいずれかを実行します。
WebLogic Serverのデータ・ソースが元のプロデューサと同じデータベースを参照するように、新しいプロデューサを構成します。
永続ストア移行ユーティリティを使用して、永続ストアを移行します(詳細は、「WSRPプロデューサの永続ストアの移行」を参照)。
ファイル永続ストア: 次のいずれかを実行します。
元のプロデューサと同じファイル・システムの場所を参照するように、新しいプロデューサを構成します。
永続ストア移行ユーティリティを使用して、永続ストアを移行します(詳細は、「WSRPプロデューサの永続ストアの移行」を参照)。
最後に、Enterprise Manager Fusion Middleware ControlまたはWLSTコマンドsetWSRPProducerRegistrationを使用して、プロデューサ登録のURLを更新します。
ポートレットを本番環境にデプロイする前に、まず、期待通りに動作することを確認するためにテストすることを強くお薦めします。
この項には次のトピックが含まれます:
統合WebLogic Server (統合WLS)は、デプロイメント・プロファイルを作成しなくても、JDeveloper内でアプリケーションを実行できるように事前に構成されているため、ポートレットを短時間で簡単にテストする手段となります。
統合WLSでJSR 286ポートレットをテストするには:
http://host:port/applicationname-Portlets-context-root/info
説明:
hostは、プロデューザがデプロイされているサーバーです。
portはHTTPリスナー・ポートです。通常、7101です。サーバーが起動すると、ポートがコンソールに表示されます。
context-rootは、Webアプリケーションのコンテキスト・ルートです。
ブラウザのウィンドウに、図13-4のようなテスト・ページが表示されます。
統合WebLogic ServerでのWSRPポートレット・プロデューサの実行時の処理
これらの構成は、ポートレットの要件によって異なります。
ポートレットをWebサービスとして構成するために、WSDLとその他の構成ファイルがWEB-INFディレクトリに追加されます。
web.xmlファイルは、JSR 286ポートレット・プロデューサ・アプリケーションを正常に実行するために必要な、リスナー・クラスとサーバー・クラス、フィルタ、パラメータ、およびその他の構成で更新されます。
例: oracle.portlet.server.adapter.web.ServerContextListenerクラス、WSRP_v2_PortletManagement_Serviceフィルタ、WSRPBaseServiceフィルタなど。
JSR 286ポートレットに必要なライブラリ(oracle.portlet-producer.wsrpなど)が、weblogic.xmlファイルに追加されます。
WSRPポートレット・プロデューサを統合WLSで実行すると、次の処理が行われます。
WSRPポートレット・プロデューサ・アプリケーションを統合WLSインスタンスで実行すると、そのインスタンスが停止したときに、アプリケーションはアンデプロイされるため使用できなくなります。より安定したテスト・シナリオの場合、デフォルト・サーバーの実行中に常に使用できるように、ポートレット・プロデューサ・アプリケーションを統合WLSにデプロイできます。
この方法を選択する場合、まずデプロイメント・プロファイルを作成する必要があります。アプリケーションを統合WLSにデプロイする場合、「デプロイメント構成」ダイアログが表示され、デプロイメント設定を構成およびカスタマイズできます。JDeveloperで事前作成されたファイル・システムMDSリポジトリが、「リポジトリ名」フィールドに表示されます。
セキュリティ上の理由から、WSRPテスト・ページを非表示にして管理者のみが確認できるようにすることも、そのページを完全に削除することもできます。
この項では、次の内容について説明します。
注意:
WebブラウザでプロデューサへのSOAPリクエストを作成できる、Webserviceテスト・ページもあります。WSRPポートレット・プロデューサについては、このページがデフォルトで無効にされています。このページには、ポートレット・プロデューサのテストについての有用な情報は示されませんが、このページを有効にすることもできます。このページを有効にするには、デプロイ済プロデューサのWARファイルからoracle-webservices.xmlファイルを抽出して、WSRP v1とWSRP v2の両方のプロデューサのexpose-testpageフラグをtrueに設定してから、WARファイルとEARファイルを再パッケージ化してプロデューサを再デプロイします。
WSRPテスト・ページをすべてのユーザーが確認する必要がない場合は、このページを管理者のみが確認できるようにして保護できます。
WSRPテストページを非表示にするには:
一般に、WebLogic PortalのEclipse IDEで開発したJSR 286標準ポートレット(Javaポートレット)は、WebCenter Portal/JDeveloper環境に直接移動できます。ポートレットのすべてのアーティファクト(portlet.xml、.javaファイル、.jspファイルなど)を、単に、JDeveloperのポートレット・プロデューサ・アプリケーション・プロジェクトにコピーします。
注意:
ポートレットで使用しているWebLogic Portal固有のAPIは、WebCenter PortalのAPIに書き直す必要があります。WebLogic Portal固有のAPIは、WebCenter環境では動作しなくなります。
ヒント:
WebLogic Portalのエクスポート機能を使用すると、Javaポートレットをアーカイブ・ファイルにエクスポートできます。このアーカイブ・ファイルは、JDeveloperのプロジェクトにインポートできます。この方法は、ポートレットのすべてのアーティファクトを環境間で手動コピーするよりも簡単です。Oracle WebLogic Portalポートレット開発ガイドの別のシステムで使用するためのJavaポートレットのエクスポートに関する項を参照してください。
WLP開発環境からWebCenter Portal開発環境へのポートレットの移行は、直接的にはサポートされていません。一般に、このプロセスには、移行したポートレットのコードと関連ファイルに対する、大幅な書き直しとリファクタリングを伴います。
注意:
WebLogic PortalのWSRPで実行可能であったポートレットは(どのタイプでも)、WebCenter Portalコンシューマに含まれるWebLogic Portalポートレット・プロデューサから直接利用できます。Oracle WebLogic Portalフェデレーテッド・ポータル・ガイドの「WSRPのOracle WebCenter PortalおよびOracle Portalとの相互運用」を参照してください。
次に、WLPポートレットをWebCenter Portalのポートレット・プロデューサ環境に移動する際の一般的なガイダンスを示します。
JSPポートレット - JSPポートレットをWebCenter Portalプロジェクトに直接移動することはサポートされていません。JSPポートレットをJSR286ポートレットにリファクタリングしてから移行することを検討できます。
JSR 168/286ポートレット - ほとんどのJava (JSR 168/286)ポートレットは、WebCenter Portalポートレット・プロデューサに直接インポートして、JSR286ポートレットとして実行できます。JSR168仕様で保証されている特定のエラー条件を利用する一部のJSR168ポートレットは、JSR168互換モードでの実行が必要になることがあります。Oracle WebLogic Portalポートレット開発ガイドのJSR-286/JSR-168ポートレットの互換性に関する項を参照してください。WLPに独自のイベント機能(.portletファイルで宣言されるイベントのサブスクリプション)を使用するJSR168ポートレットは、JSR286のイベントを使用するように書き直す必要があります。
Javaページ・フロー・ポートレット – JPFポートレットは、WebCenter Portalのポートレット・プロデューサではサポートされていないため、WebLogic Portal WSRPプロデューサから使用するか、JSR286またはJSFポートレットとなるようにリファクタする必要があります。
JSFポートレット – このポートレットが、WLPでJSR329 JSFポートレット・ブリッジに書き込まれる場合、WebCenterプロデューサでそのまま実行する必要があります。WLPの"ネイティブ" JSFポートレット・ブリッジを使用するポートレットについては、そのポートレットをWebLogic Portalプロデューサから利用するか、JSR329ブリッジを使用するJSF 1.2ポートレットにアップグレードする必要があります。Oracle WebLogic Portalポートレット開発ガイドの「JSF-Javaポートレットの使用」も参照してください。
Clipperポートレット - ClipperポートレットはWebCenter Portalではサポートされていませんが、WebCenter Portalのページレット・プロデューサのWebクリッピング機能により、同等の機能が提供されます。
Strutsポートレット - StrutsポートレットをWebCenter Portalプロジェクトに直接移動することはサポートされていません。JSPポートレットをJSR286ポートレットにリファクタリングしてから移行することを検討できます。
コンテンツ・プレゼンタ・ポートレット – WLPコンテンツ・プレゼンタ・ポートレットは、WSRPおよびWebCenter Portalでは機能しません。ただし、これに相当する機能がWebCenter Portalのコンテンツ・プレゼンタでは使用できます。『Oracle WebCenter Portalでのポータルの構築』のコンテンツ・プレゼンタによるコンテンツの公開に関する項を参照してください。
リモート(WSRP)ポートレット – WLPで使用されるリモート(WSRP)ポートレットは、かわりにWebCenter Portalのコンシューマで使用できます。WLP固有のWSRP機能を利用するリモート・ポートレットには、変更が必要になることがあります。たとえば、カスタムのデータ・転送機能は、データを伝達するためのイベントまたは共有パラメータを使用して置き換える必要があります。Oracle WebLogic Portalフェデレーテッド・ポータル・ガイドの「WSRPのOracle WebCenter PortalおよびOracle Portalとの相互運用」および「WLPとWebCenter Portal: Frameworkアプリケーション間のWSRPセキュリティの構成」を参照してください。
WebLogic Portalポートレットを、JDeveloperのWebCenter Portalプロジェクトに直接移動すると、次の特有の問題が発生することがあります。
URL生成 – WebLogic PortalでサポートされるURLタイプには、WebCenter Portalで機能しないものもあります(DesktopURL、CustomEventURL、PageURL、WindowURL、StandalonePortletURLなど)。
イベント – WebCenter Portalコンシューマでは、WebLogic Portalフレームワークで生成されるすべてのイベントが生成されるわけではありません。これに該当するサポートされないイベントには、Init、LookAndFeelReinit、Notification、Refresh、WindowActivation、WindowDeactivationなどがあります。
レンダリングの依存性 - WLPのレンダリングの依存性は、WebCenter Portalでは機能しません。
WLP Framework API – 多数のWLP APIがWebCenter Portalではサポートされません。
この項では、JSR 286ポートレットを構築する際に作成されるファイルについて説明します。次のトピックが含まれています:
portlet.xmlは、JSR 286ポートレットの特性を定義します。portlet.xmlの詳細は、次で入手できるJavaポートレット仕様を参照してください。
http://jcp.org/en/jsr/detail?id=168
次の例は、portlet.xmlファイルのサンプル・フラグメントです。この例には、portlet.xmlの使用可能な要素がすべて含まれているわけではありません。
portlet.xmlの例
<portlet> <description xml:lang="en">JSR 286 map portlet </description> <portlet-name>portlet1</portlet-name> <display-name xml:lang="en">Map Portlet</display-name> <portlet-class>jsrportlet.MapPortlet</portlet-class> <expiration-cache>0</expiration-cache> <supports> <mime-type>text/html</mime-type> <portlet-mode>edit</portlet-mode> <portlet-mode>help</portlet-mode> <portlet-mode>about</portlet-mode> </supports> <supported-locale>en</supported-locale> <resource-bundle>jsrportlet.resource.MapPortletBundle</resource-bundle> <portlet-info> <title>Map Portlet</title> <short-title>Map</short-title> <keywords/> <portlet-preferences> <preference> <name>portletTitle</name> </preference> </portlet-preferences> <security-role-ref> <role-name>viewer</role-name> </security-role-ref> </portlet>
JSR 286ポートレットの場合、portlet.xmlファイルには、ポートレットおよびそれらの設定関連の情報がすべて含まれています。前のサンプルでは、これらの設定がすべて使用されているわけではありません。
<description>: エンド・ユーザーに詳細情報を提供するポートレットについて説明します。
<portlet-name>: ポートレット・アプリケーション内でポートレット・プロデューサ・アプリケーションを一意に識別します。
<display-name>: ユーザーに使用可能なポートレットのリストを表示するときに使用します。
<portlet-class>: javax.portlet.Portletインタフェースを実装するクラス、またはポートレット・ロジックのエントリ・ポイントとなるGenericPortlet抽象クラスを拡張するクラスの完全修飾クラス名が入ります。ポートレット・コンテナは、ポートレット・ライフ・サイクル・メソッドを起動するときにこのクラスを使用します。Oracle JSF Portlet Bridgeを使用して作成されるJSFポートレットの場合、これはoracle.portlet.bridge.adf.application.ADFBridgePortletになります。
<expiration-cache>: 有効期限のキャッシュのデフォルトの期間です。
<init-param>: ポートレットの動作を構成する初期化パラメータを定義します。Oracle JSF Portlet Bridgeは、表示モードなど、ポートレットでサポートされる別のポートレット・モデルのエントリ・ポイントを識別するために初期化パラメータを使用します。
<init-param> <name>javax.portlet.faces.defaultViewId.view</name> <value>/myPage.jspx</value> </init-param>
他のWebCenter Portal対応モードの初期化パラメータは、次のとおりです。
編集モード: javax.portlet.faces.defaultViewId.edit
ヘルプ・モード: javax.portlet.faces.defaultViewId.help
情報モード: javax.portlet.faces.defaultViewId.about
構成モード: javax.portlet.faces.defaultViewId.config
デフォルト編集モード: javax.portlet.faces.defaultViewId.edit_defaults
プレビュー・モード: javax.portlet.faces.defaultViewId.preview
印刷モード: javax.portlet.faces.defaultViewId.print
注意:
defaultViewIdの値はアプリケーションのコンテキスト・ルートと関連しており、必ず/で始まる必要があります。例では、defaultViewId.viewの値が/myPage.jspxに指定されています。
defaultViewIdに他のポートレット・モードを追加する場合は、<supports>タグにもモードを追加する必要があります。たとえば、<portlet-mode>HELP</portlet-mode>のようになります。
<supports>: コンテンツ・タイプごとにサポートされているポートレット・モードについての情報を提供します。WebCenter Portalでサポートされているポートレット・モードには、edit、help、about、config、edit_defaults、previewおよびprintがあります。
<supported-locale>: ポートレットで実行時にサポートされるロケールをリストします。
<resource-bundle>: リソース・バンドルの完全修飾クラス名で、タイトルやキーワードなど、言語専用のポートレット情報提供するために使用されます。
<title>: ポートレットの静的タイトル。通常は、ポートレット・ウィンドウ上のポートレットの装飾内で表示されます。
<short-title>: 表示能力が限られているデバイス(携帯電話など)で使用されるタイトル。
<keywords>: ユーザーに検索能力を提供するアプリケーションで使用されます。
<portlet-preferences>: プリファレンス属性定義です。
<supported-processing-event>: ポートレットで受信可能なイベントです。
<supported-publishing-event>: ポートレットを呼び出すイベントです。
<supported-public-render-parameter>: ポートレットでサポートされるパブリック・レンダラ・パラメータです。
<container-runtime-option>: 追加の実行時の動作を定義するオプションです。
<security-role-ref>: web.xmlでセキュリティ・ロールにロール名をマップします。<security-role-ref>をマップする先のweb.xml内にあるロールのリストは、プロデューサのユーザー・カテゴリとしてコンシューマに公開されます。web.xmlでは、<security-role>は次のように表示されます。
<security-role> <description>Viewer role</description> <role-name>viewer</role-name> </security-role>
ポートレット用に作成するポート・モードの実装スタイルに応じて、対応するJSPファイルが、そのモードを定義するためにportlet_name\htmlディレクトリに作成されます。たとえば、ポートレットに表示モードと編集モードを使用する場合、portlet_name\htmlディレクトリにview.jspとedit.jspが必要になります。JSR 286ポートレットの場合、使用するポートレット・モードに対して次のJSPファイルが作成されます。
about.jsp
config.jsp
edit_defaults.jsp
edit.jsp
help.jsp
preview.jsp
print.jsp
view.jsp
ポートレット・モードの詳細は、「ポートレット・モード」を参照してください。
portlet_name.javaは、ポートレット・ロジックのエントリ・ポイントの役割を果すクラスです。このクラスは、javax.portlet.Portletインタフェースを実装するか、GenericPortlet抽象クラスを拡張する必要があります。ポートレット・コンテナは、ポートレット・ライフ・サイクル・メソッドを起動するときにこのクラスを使用します。
