フィーチャーの管理

フィーチャーとは、特定のサーバーにロードされる、ランタイム環境の一部分を制御する機能単位です。

構成ファイル server.xml を使用して、ロードするフィーチャーを宣言します。 一連のフィーチャーを <featureManager> エレメント内に入れ、個々のフィーチャーを <feature> サブエレメント内に入れます。以下に例を示します。
<server>
  <featureManager>
    <feature>servlet-3.0</feature>
    <feature>localConnector-1.0</feature>
  </featureManager>
</server>

サーバー構成ファイルには任意のフィーチャーを指定できます。 フィーチャーによっては、その中に別のフィーチャーを含むものもあります。 同一のフィーチャーが、他の 1 つ以上のフィーチャーに含まれることもあります。 実行時に、フィーチャー・マネージャーは、要求されたフィーチャー・セットをサポートするために必要な内容を組み合わせたリストを算出します。

使用可能な主なフィーチャーについては、『Liberty フィーチャー』を参照してください。 各フィーチャーの制約事項については、『ランタイム環境での既知の問題および制約事項』を参照してください。

フィーチャー構成の動的変更

フィーチャー構成を変更すると、フィーチャー・マネージャーが必要なバンドルのリストを再度判断し、不要なバンドルを停止してアンインストールし、追加のものをインストールして開始します。そのため、すべてのフィーチャーは、他のフィーチャーの動的な追加または削除に対応できるように設計されています。

[8.5.5.4 以降]

singleton フィーチャー

Java™ EE 7 用の最初のフィーチャー・セットが配信されたため、現在、この同じフィーチャーに以下の 2 つのバージョンがあります。
  • servlet-3.0
  • servlet-3.1
他のアプリケーション・サーバーとは異なり、サーバー構成で使用するこのフィーチャーのバージョンを選択できます。servlet-3.0 は既存のアプリケーションの動作を保持します。一方、servlet-3.1 は、新規アプリケーションまたは変更されたアプリケーションの新しい機能を提供します。仕様バージョンを選択できますが、2 つのバージョン間の個々の差異を制御するための追加構成プロパティーは不要であり、提供もされていません。
サーブレット・フィーチャーは singleton フィーチャーです。つまり、1 つのサーバーで使用するために構成できるバージョンは 1 つのみ (servlet-3.0 または servlet-3.1 のいずれか) です。 異なるバージョンのサーブレット・フィーチャーを必要とするアプリケーションがある場合、別のサーバーにデプロイする必要があります。他の多くのフィーチャーには、依存関係としてサーブレット・フィーチャーが含まれています。WebSphere® Liberty 製品では、そうしたフィーチャーは、いずれのバージョンでも機能するように更新されています。これにより、servlet-3.1 を使用した場合はフィーチャーの完全な「スタック」を構成できますが、他のソースからのフィーチャーは、servlet-3.1 を「許容」するように更新されていない可能性があります。 フィーチャーが servlet-3.1 を「許容」できるようにするには、以下のようにフィーチャー・マニフェストを変更します。
Subsystem-Content: com.ibm.websphere.appserver.servlet-3.0; ibm.tolerates:="3.1"; type="osgi.subsystem.feature"
server.xml ファイルでの直接的な構成か、フィーチャー依存関係によって、サーバー構成に複数のバージョンの singleton フィーチャーが含まれている場合、構成エラーとなるため、いずれのバージョンのフィーチャーもロードされません。このエラーが原因で、以下のようなメッセージが生成されます。
[ERROR ] CWWKF0033E: singleton フィーチャー servlet-3.1 と servlet-3.0 は、同時にロードできません。構成済みフィーチャー servlet-3.1 と servlet-3.0 には、競合の原因となるフィーチャーが 1 つ以上組み込まれています。
この問題を解決するには、構成されているすべてのフィーチャーが同じバージョンの当該 singleton フィーチャーを指定するか、許容するようにします。両方のフィーチャー・バージョンがどうしても必要な場合、異なるサーバーに一部のアプリケーションを移動します。

置き換えられたフィーチャー

フィーチャーの superseded ラベルは、新規フィーチャーまたはフィーチャーの組み合わせにより、置き換えられたフィーチャーを使用した場合よりも利点が得られる可能性があることを示しています。例えば、新規のより詳細なフィーチャーを、置き換えられたフィーチャーの代わりに使用して、必要でない可能性があるコンテンツを除外することで、サーバー・フットプリントを削減できます。 新規フィーチャーによって、置き換えられたフィーチャーの機能が完全に置き換えられるとは限らないため、構成を変更するかどうかを決定する前に、自分のシナリオを検討する必要があります。置き換えられたフィーチャーは引き続き完全にサポートされて有効であり、構成で使用できます。superseded ラベルは、構成を改善することができる可能性があるということを示すだけのものです。

非常にまれに、他のフィーチャーを含むフィーチャーが、そのフィーチャーの新しいバージョンで置き換えられたときに、前に含まれていたすべてのフィーチャーは含まないことがあります。 新しいバージョンに含まれないそれらのフィーチャーは、分離された とみなされます。 分離されたフィーチャーの機能をアプリケーションで使用する必要がある場合は、その分離されたフィーチャーをご使用の構成に明示的に追加する必要があります。

例えば、featureA と featureB が以下の状態であるとします。
  • featureA-1.0 は featureB-1.0 を含む
  • featureA-2.0 は featureB-1.0 (および featureB のそれ以降のバージョン) を含まない
アプリケーションで featureB の機能を使用する場合、以下のいずれかの構成で実現できます。
  • server.xml ファイルに featureA-1.0 を組み込む
  • server.xml ファイルに featureA-2.0 と featureB-1.0 を組み込む

トピックのタイプを示すアイコン 概念トピック

インフォメーション・センターに関するご使用条件 | フィードバック


タイム・スタンプ・アイコン 最終更新: 2015 年 6 月 17日
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-libcore-mp&topic=cwlp_feat_mgmt
ファイル名: cwlp_feat_mgmt.html