Liberty: ランタイム環境での既知の問題および制約事項
Liberty のランタイム環境で作業する際に適用される既知の制約事項がいくつかあります。

『Liberty: Developer Tools の既知の制約事項』も参照してください。
既知の問題および制約事項のリスト:
- 一般的な制約事項:
- Java の最小サポート・レベル
- インストール・ディレクトリー名およびパスに 非 ASCII 文字は使用できない
- 実行時に JDBC データ・ソースを変更すると、JPA で障害が発生することがある
- getRealPath で返される結果に依存するアプリケーションは、 WAR ファイルではなく、展開されたアプリケーションとしてデプロイする必要がある
- WebSphere Application Server traditional のスクリプトは Liberty で動作しない
- fileset の制約事項
共有ライブラリーを非公開にしたとき、サーバーが停止するまでそれを削除できない
- java:global 検索の制約事項
- 組み込み Liberty サーバーでアプリケーションが開始されない
- WebSphere MQ リソース・アダプターおよび汎用 JCA サポートに関連した制約事項
- dropins ディレクトリー内のアプリケーションのバージョン管理はできない
- 共有セッション・アプリケーションは、セッション・オブジェクトを共有ライブラリーに保管しなければならない
- Liberty フィーチャーに固有の制約事項:
- Admin Center フィーチャーの制約事項
- appClient-1.0 フィーチャーの制約事項
- appSecurity-2.0 フィーチャーの制約事項
- Bean 検証フィーチャーの制約事項
- collectiveController-1.0 フィーチャーの制約事項
- concurrent-1.0 フィーチャーの制約事項
- 動的キャッシュ・フィーチャーの制約事項
- Enterprise JavaBeans (EJB) フィーチャーの制約事項
- j2eeManagement-1.1 フィーチャーの制約事項
- jacc-1.5 フィーチャーの制約事項
- jaxb-2.2 フィーチャーの制約事項
- jaxws-2.2 フィーチャーの制約事項
- jpa-2.1 フィーチャーの制約事項
- jsf-2.2 フィーチャーの制約事項
- jsp-2.2 フィーチャーの制約事項
- logstashCollector-1.0 フィーチャーの制約事項
- logmetCollector-1.0 フィーチャーの制約事項
- monitor-1.0 フィーチャーの制約事項
- requestTiming-1.0 フィーチャーの制約事項
- restConnector-1.0 フィーチャーの制約事項
- scim-1.0 フィーチャーの制約事項
- sipServlet-1.1 フィーチャーの制約事項
- wmqJmsClient-1.1 フィーチャーの制約事項
- wmqJmsClient-2.0 フィーチャーの制約事項
- dataSource、jdbcDriver、connectionManager、および JDBC ベンダー・プロパティーを実行時に変更すると、JPA で障害が発生する可能性がある
Java の最小サポート・レベル
- Java SE 6 ランタイム環境
- IBM の Java SDK の場合、サポートされる最小レベルは 6.0 (J9 2.6) SR 1 です。Oracle の JDK の場合、サポートされる最小レベルは Java 6 Update 26 です。
Java SE 6 は、IBM i V7R3 ではサポートされません。
- Java SE 7 ランタイム環境
- IBM の Java SDK の場合、サポートされる最小レベルは IBM Runtime Environment, Java Technology Edition 7.0.4.1 です。 Windows および Linux の Oracle の JDK の場合、サポートされる最小レベルは Java SDK/JRE/JDK 7.0.17 です。 Mac OS X の Oracle の JDK の場合、サポートされる最小レベルは Java SDK/JRE/JDK 7.0 Update 15 です。
- Java SE 8 ランタイム環境
- IBM の Java SDK の場合、サポートされる最小レベルは IBM SDK, Java Technology Edition バージョン 8 です。Oracle の JDK の場合、サポートされる最小レベルは Java 8 Update 25 です。
分散プラットフォームでは、32 ビットまたは 64 ビットの Java がサポートされます。
Windows システムおよび
Linux システムでは、
Oracle の JDK または IBM の Java SDK のいずれかを使用することができます。
Windows または Linux でアプリケーションを開発していて、WebSphere Application Server traditional で稼働するサーバーにそれらのアプリケーションをデプロイする予定の場合は、
IBM の Java SDK を使用してください。HP システムおよび Mac OS では、Oracle の JDK を使用してください。

IBM i V7R3 の場合、最小 JDK レベルは IBM Java SE 7.0 32 ビット JVM (5770-JV1 オプション 14) またはIBM Java SE 7.0 64 ビット JVM (5770-JV1 オプション 15) です。
インストール・ディレクトリー名およびパスに 非 ASCII 文字は使用できない
最近の JVM は、-jar コマンドおよび -javaagent コマンドでの非 ASCII 文字の使用を完全にはサポートしていません。 インストール・ディレクトリー名およびパスには ASCII 文字のみを使用してください。
実行時に JDBC データ・ソースを変更すると、JPA で障害が発生することがある
データベース・ディクショナリー・タイプがプロパティーで指定されない場合、最初のエンティティー・マネージャーが作成されてデータベース接続が行われたときに、OpenJPA がそのタイプの検出および算出を行います。 このデータベース・ディクショナリー・タイプは、その後作成されるすべてのエンティティー・マネージャーに使用されます。 アプリケーションの実行中に JDBC データ・ソースが変更されると、 エンティティー・マネージャー・ファクトリーはこの変更を検出せずに、新しいデータ・ソースの操作に古いディクショナリーを使用し続けます。 データベースが別のベンダーに変更された場合、これにより障害が発生する可能性があります。
データベースを別のベンダーに変更した場合は、アプリケーションを再始動してください。
dataSource、jdbcDriver、connectionManager、および JDBC ベンダー・プロパティーを実行時に変更すると、JPA で障害が発生する可能性がある
サーバーの稼働中に dataSource、jdbcDriver、connectionManager、または いずれかの JDBC ベンダー・プロパティー・リスト (例えば、properties.db2.jcc または properties.oracle など) の構成を更新すると、 J2CA8040E の障害が発生することがあります。 これらの障害では、複数の dataSource エレメントを単一の connectionManager に関連付けられないことに言及しています。 構成で 1 つの connectionManager だけを dataSource エレメントに関連付けている場合にも、これらの障害は生成されます。
これらのいずれかの JDBC リソースの構成を更新したら、サーバーを再始動してください。
getRealPath で返される結果に依存するアプリケーションは、 WAR ファイルではなく、展開されたアプリケーションとしてデプロイする必要がある
Java EE 仕様では、コンテンツが Web アーカイブ (WAR) ファイルから使用可能になっている場合に、 getRealPath() メソッドが null 値を返すことを規定しています。 WAR ファイルを Liberty にデプロイした場合、 Liberty はアーカイブ・ファイルをディレクトリー構造に自動的に解凍しません。 そのため、アプリケーションを開始できないことがあります。 getRealPath() で返される結果にアプリケーションが依存する場合には、 アプリケーションを WAR ファイルではなく、展開された Web アプリケーションとしてデプロイする必要があります。 例えば、手動で WAR ファイルを解凍して、展開されたアプリケーションを dropins ディレクトリーにコピーすることができます。
WebSphere Application Server traditional のスクリプトは Liberty で動作しない
WebSphere Application Server traditional の bin ディレクトリーの下にあるスクリプトはどれも、Liberty の管理には使用できません。
fileset の制約事項
- fileset は、ベース・ディレクトリーのサブディレクトリーを再帰的に探索しません。
例えば、次の指示はサポートされません。
<fileset id="testFileset" dir="\temp" includes="**\a.jar"/> <fileset id="testFileset" dir="\temp" includes="a\a.jar"/> <fileset id="testFileset" dir="\temp" includes="*\a.jar"/> <fileset id="testFileset" dir="\temp" includes="a\b\a.jar"/>

共有ライブラリーを非公開にしたとき、サーバーが停止するまでそれを削除できない
サーバーから共有ライブラリーを非公開にした場合、ライブラリー JAR ファイルはサーバーから即時に解放されません。 そのため、オペレーティング・システムは、そのファイルがもう使用されていないことを認識しておらず、そのファイルの削除を許可しません。 次にサーバーを停止すると、ライブラリー JAR ファイルが解放され、ファイルを削除できるようになります。
java:global 検索の制約事項
java:global 検索でアプリケーション内に定義されたリソースは、現行サーバーにデプロイ済みのアプリケーションによって宣言された名前にアクセスする場合のみ使用可能です。
組み込み Liberty サーバーでアプリケーションが開始されない
組み込み Liberty サーバーを開始する Java プロセスが、libertyInstallDir/bin/tools/ws-javaagent.jar を指す -javaagent JVM 引数を使用して開始されたことを確認してください。-javaagent JVM 引数が使用されていない場合は、サーバー・ランタイムは開始されますが、明確な例外なしに、アプリケーションは開始に失敗します。
WebSphere MQ リソース・アダプターおよび汎用 JCA サポートに関連した制約事項
WebSphere® MQ リソース・アダプターは、wmqJmsClient-1.1 フィーチャーまたは wmqJmsClient-2.0 フィーチャーまたは汎用 JCA サポートを使用して、WebSphere Application Server Liberty 内で使用することができます。
Liberty のバージョン 8.5.5 以降で WebSphere MQ リソース・アダプターのバージョン 7.5 を使用できます。JMS 2.0 リソース・アダプターに基づいている WebSphere MQ リソース・アダプターのバージョン 8.0 を使用する場合、JMS 2.0 リソース・アダプターとの互換性がある最新の Liberty のバージョンを使用してください。
- Liberty のバージョン 8.5.5.2 では、wmqJmsClient-1.1 フィーチャーは、IBM MQ リソース・アダプターのバージョン 7.5.0.5 以降とともに使用する必要があります。
- Liberty のバージョン 8.5.5.6 では、wmqJmsClient-2.0 フィーチャーは、IBM MQ リソース・アダプターのバージョン 8.0.0.3 以降とともに使用する必要があります。
WebSphere MQ リソース・アダプターと Liberty 間のバージョン互換性情報について詳しくは、 WebSphere MQ リソース・アダプターを入手するための参照資料を参照してください。
- IBM® WebSphere MQ リソース・アダプターを z/OS® 上で実行するには、wmqJmsClient-1.1 または wmqJmsClient-2.0 フィーチャーを使用する必要があります。
- トレースおよびロギングは、汎用 JCA を使用して Liberty トレース・システム内に組み込まれていません。トレースは別のファイルに書き込まれ、システム・プロパティーを設定して使用可能にする必要があります。トレースを使用可能にする手順は、Java Standard Environment での JMS トレース機能用の WebSphere MQ クラスを構成する場合と同じです。『Java 標準環境トレース・スタンザ』を参照してください。
- Java の IBM MQ クラスは、Liberty ではサポートされません。これらは、IBM MQ Liberty メッセージング・フィーチャーおよび汎用 JCA サポートのどちらとも、一緒に使用してはなりません。 詳しくは、Using WebSphere MQ Java Interfaces in J2EE/JEE Environmentsを参照してください。
dropins ディレクトリー内のアプリケーションのバージョン管理はできない
dropins ディレクトリー内のアプリケーションの場合、 アプリケーション・モニターはファイル名とファイル拡張子を使用して、アプリケーションのタイプを判別し、 アプリケーション ID とアプリケーション名を生成します。そのため、ファイル名またはファイル拡張子を使用して、アプリケーションのバージョン番号を指定することはできません。実稼働環境では、dropins ディレクトリーの仕様はお勧めできません。
共有セッション・アプリケーションは、セッション・オブジェクトを共有ライブラリーに保管しなければならない
shared-session-context アプリケーション拡張機能、つまり ibm-application-ext.xml で <shared-session-context value="true"/> を使用する場合、 セッションで保管されるオブジェクトはすべて、そのセッションを無効にできるように、アプリケーションに関連付けられた共有ライブラリーで入手可能でなければなりません。
Admin Center フィーチャーの制約事項
![[16.0.0.4 以降]](../ng_v16004.gif)
- リモート・マシンからのジョブ・ログは、セキュリティー認証の問題から表示することはできません。
- インスタンス・ログが表示され、複数のホストにわたって実行される場合は、エラーが予想されます。
- 最新の更新インスタンスに従ってソートされる、フィルタリングされてい ないリストは、結果のみ表示します。
- all でフィルタ リングを実行する場合は、結果は最新の更新インスタンスでソートされません。
- リストがフィルタリングされているかどうかにかかわらず、50 個以下の結果のみリストに表示されます。
- Java Batch ベータを使用すると、batchManagement-1.0 フィーチャーを指定した永続データベースの使用が必要となります。
appClient-1.0 フィーチャーの制約事項
- このフィーチャーは Java EE アプリケーション・クライアントをサポートしていません。起動できるのはスタンドアロン・クライアント・プログラムのみです。
appSecurity-2.0 フィーチャーの制約事項
- EJB アプリケーションに対して、ibm-ejb-jar-ext.xml ファイルの拡張設定において SYSTEM_IDENTITY の run-as-mode は サポートされません。
- getCallerIdentity API は、singleton セッション Bean にはサポートされていません。
- ロール名は HttpServletRequest.isUserInRole および EJBContext.isCallerInRole API によって参照するか、または、 デプロイメント記述子内で @DeclareRoles アノテーションまたは <security-role/> エレメントを 使用して最初にロール名を宣言することなく、デプロイメント記述子内のエレメントによって参照できます。ただし、ロールは、WebSphere Application Server traditional で使用する前に宣言されている必要があります。
Bean 検証フィーチャーの制約事項
- OSGi アプリケーション内の Bean 検証はサポートされません。
- OSGi アプリケーション内の Bean 検証はサポートされません。
- beanValidation-1.0 フィーチャーとともに、validation.xml ファイルのカスタム ConstraintValidatorFactory 実装を提供するアプリケーションは、Bean Validation 1.1 API に対してコンパイルされません。
- validation.xml ファイルが、関連付けられたモジュールにない場合、
1 つだけの validation.xml ファイルが存在可能で、以下のいずれかのファイルで
com.ibm.ws.beanvalidation.allowMultipleConfigsPerApp プロパティーが
false に設定されていなければなりません。
- jvm.options
-Dcom.ibm.ws.beanvalidation.allowMultipleConfigsPerApp=false
- bootstrap.properties
com.ibm.ws.beanvalidation.allowMultipleConfigsPerApp=false
- jvm.options
動的キャッシュ・フィーチャーの制約事項
- キャッシュ複製はサポートされません。
- ハイパフォーマンスのディスク・キャッシング・モードのみがランダムおよびサイズ・ベースの排除手法でサポートされます。
- Web サービス・クライアント・サイドとサーバー・サイドのキャッシングおよび cachespec.xml ファイル内のポートレット・キャッシュはサポートされません。
- SingleThreadModel サーブレットのサーブレット・キャッシングはサポートされません。
- プロパティー・ファイルを使用したキャッシュ構成の定義は、Enterprise JavaBeans (EJB) のみを含む JAR ファイルではサポートされません。
- ヒープ・キャッシュ・サイズの制限は 32 ビットの Java 仮想マシン (JVM) でのみ有効です。
Enterprise JavaBeans (EJB) フィーチャーの制約事項
- EJB Lite フィーチャーのみを使用している場合、バージョン 3.0 より前の EJB モジュールはサポートされません。これは、EJB Lite に EJB ホームが含まれていないためです。この制約事項は、.xml ファイル形式ではなく .xmi ファイル形式を使用したバインディングおよび拡張がサポートされないことも表しています。
- セッション Bean が ejblocal 名前空間にバインドされません。つまり、JNDI 検索および ejb-ref バインディング名は、java:global 名、java:app 名、または java:module 名を使用する必要があります。simple-binding-name エレメントとインターフェース binding-name エレメントは、ibm-ejb-jar-bnd.xml ファイルで無視されます。
- ステートフル Bean 非活性化ディレクトリーは構成できません。 ファイルはサーバー作業域に非活性化されます。
j2eeManagement-1.1 フィーチャーの制約事項
j2eeManagement-1.1 フィーチャーには次の制約があります。
- 管理 EJB の getListenerRegistry() メソッドはサポートされません。管理 EJB コンポーネントでイベント通知リスナーを登録できません。
jaxb-2.2 フィーチャーの制約事項
- JAXB API クラスを必要とするアプリケーションが既に開始されており、かつ jaxb-2.2 サーバー・フィーチャー を有効にする場合は、jaxb-2.2 フィーチャーによって提供される JAXB 2.2 API および実装クラスをアプリケーションが呼び出すことができるように、--clean オプションを指定してサーバーを再始動する必要があります。そうしないと、アプリケーションは Java SDK で提供される JAXB API および 実装クラスにバインドしたままになる可能性があります。
- jaxb-2.2 サーバー・フィーチャーが有効になっているときに、独自の JAXB API および実装クラスをアプリケーションで使用したい場合は、独自の JAXB API および実装 JAR ファイルをアプリケーションの /WEB-INF/lib ディレクトリーに置き、アプリケーションのクラス・ローダーを、parentLast 委任動作を使用するように構成する必要があります。そうしないと、jaxb-2.2 フィーチャーによって提供される JAXB API および実装クラスが常に有効になります。Liberty でのアプリケーション用クラス・ローダー動作の構成について詳しくは、代替バージョンでの提供 API のオーバーライドを参照してください。
jaxws-2.2 フィーチャーの制約事項
- アプリケーションが CXF JAR ファイルの独自のコピーを、 例えば Web アプリケーションの WEB-INF/lib ディレクトリー内に、 アプリケーション・ライブラリーとして用意する場合、 server.xml ファイル内の jaxws-2.2 フィーチャーを有効にすることはできません。
- jaxws-2.2 フィーチャーは jaxb-2.2 フィーチャーに 依存するため、jaxb-2.2 フィーチャーの制約事項は jaxws-2.2 フィーチャーにも適用されます。
- JAX-WS API クラスを必要とするアプリケーションが既に開始されており、かつ jaxws-2.2 サーバー・フィーチャーを有効にする場合は、jaxws-2.2 フィーチャーによって提供される JAX-WS 2.2 API および実装クラスをアプリケーションが呼び出すことができるように、--clean オプションを指定してサーバーを再始動する必要があります。そうしないと、アプリケーションは Java SDK で提供される JAX-WS API および 実装クラスにバインドしたままになる可能性があります。
- Liberty 用の Web サービス・バインディング・ファイルは ibm-ws-bnd.xml ファイルです。以下に示す WebSphere Application Server traditional 用の Web サービス・バインディング・ファイルはサポートされていません。
- ibm-webservices-ext.xmi
- ibm-webservices-bnd.xmi
- ibm-webservicesclient-ext.xmi
- ibm-webservicesclient-bnd.xmi
- ws-security.xml
- Apache Axis2 構成またはクラスはサポートされません。
- javax.xml.ws.Provider<OMElement> または javax.xml.ws.Provider<String> インターフェース を実装する Web サービス・プロバイダーはサポートされていません。
- Liberty では、MIME 添付ファイルの content-id 属性は不等号括弧で囲まれている必要があります。例えば、<testID> です。
- -inlineSchemas オプションは、Liberty によって提供される wsgen ツールではサポートされません。
- JAX-WS Web サービスを使用して大きいバイナリー・データを転送する場合は、メモリー不足 (OOM) エラーを避けるために、MTOM を使用可能にします。
- Web サービス・アプリケーションについては、サービス・クライアントとサービス・プロバイダーが同じアプリケーションに含まれておらず、サービス・プロバイダー・アプリケーション内の WSDL ファイルが変更された場合、WSDL 定義キャッシュの問題を避けるために、Web サービス・クライアント・アプリケーションを手動で再始動する必要があります。
jsf-2.2 フィーチャーの制約事項
- jsf-2.2 フィーチャーを faces-config.xml ファイルと一緒に使用して、バージョン 2.2 および名前空間を指定すると、エラーが発生します。
- jsf-2.2 を cdi-1.2、ejb-3.2、および jpa-2.1 と共に有効にすると、フィーチャーの競合が発生します。
jsp-2.2 フィーチャーの制約事項
- 変換された JSP ファイルをメモリーにのみ保管する useInMemory 構成オプションのサポートはありません。
logstashCollector-1.0 フィーチャーの制約事項
logstashCollector-1.0 フィーチャーには、以下の制約事項が適用されます。- データ損失 – Liberty で生成されたイベントの一部が、予期どおりに Logstash に転送されない場合があります。
データ損失は、以下のシナリオで発生する可能性があります。
- Logstash サーバーが始動される前に Liberty サーバーを始動。 Logstash サーバーを始動してから Liberty サーバーを始動することをお勧めします。
- 重負荷条件。 Liberty のイベント・パイプライン、Logstash、およびその他のダウンストリームのコンシューマーがイベントを処理可能な速度を超えて、Liberty でイベントが作成されるケースでは、 イベントがドロップされる可能性があります。 イベント作成がイベント消費より一時的に速い場合、Liberty はバッファーを使用してデータ損失を回避します。
- logstashCollector-1.0 フィーチャーは、Logstash V2.x でテストが行われ、これと互換性があります。
logmetCollector-1.0 フィーチャーの制約事項
logmetCollector-1.0 フィーチャーには、以下の制約事項が適用されます。- データ損失 – Liberty で生成されたイベントの一部が、予期どおりに logmet に転送されない場合があります。データ損失は、以下のシナリオで発生する可能性があります。
重負荷条件。 Liberty のイベント・パイプライン、logmet、およびその他のダウンストリームのコンシューマーがイベントを処理可能な速度を超えて、Liberty でイベントが作成されるケースでは、イベントがドロップされる可能性があります。イベント作成がイベント消費より一時的に速い場合、Liberty はバッファーを使用してデータ損失を回避します。
- 接続損失 - Bluemix® での logmet サービスへの接続が頻繁に切断されます。
monitor-1.0 フィーチャーの制約事項
- このフィーチャーが server.xml ファイルから 削除される場合、JAX-WS アプリケーションが機能するようサーバーを再始動する必要があります。
requestTiming-1.0 フィーチャーの制約事項
- requestTiming-1.0 フィーチャーは、アクティブ化されている場合、DayTrader アプリケーションで測定すると、最大可能アプリケーション・スループットに 4% の悪影響を与えることが分かっています。ご使用のアプリケーションへの影響ではこの数値が前後する可能性がありますが、パフォーマンスの低下が顕著になる可能性があることに留意する必要があります。
restConnector-1.0 フィーチャーの制約事項
restConnector-1.0 フィーチャーには次の制約があります。
- restConnector-1.0 フィーチャー、または restConnector-1.0 を含む任意のフィーチャー (collectiveMember-1.0 や collectiveController-1.0 など) のユーザーがカスタム JAXRS 2.0 ランタイムを含むアプリケーションを実行する場合、jaxrs-2.0 フィーチャーをそのサーバーに追加する必要があります。
scim-1.0 フィーチャーの制約事項
- groups を検索しているときに members 属性は取得されません。
- users を検索しているときに users の groups 属性は取得されません。
- users の groups 属性に direct/indirect の正規タイプは設定できません。
- 正規タイプ work のユーザーの email 属性は、1 つだけ定義可能です。
- 正規タイプ work のユーザーの ims 属性は、1 つだけ定義可能です。
- entitlements、roles、x509Certificates などの、SCIM の拡張スキーマ属性は、 設定することも、戻すこともできません。
- userName 属性をフィルター内で他の属性と一緒に使用することはできません。
- 基本レジストリーと SAF レジストリーのユーザーには、userName、 displayName、id、schema、 meta.location、および groups のみを設定できます。 userName と displayName は、同じ値になります。
- 基本レジストリーおよび SAF レジストリーによるリスト/照会の動作は、ldapRegistry レジストリーと同じではありません。
- pr、gt、ge、 lt、le、and、or、 () などの演算子は、基本レジストリーおよび SAF レジストリーで動作しません。 また、基本レジストリーおよび SAF レジストリーには、フィルターで 1 つの演算子だけを使用する必要があります。
- 基本と SAF は読み取り専用レジストリーです。
- user を作成しているときに、groups 属性は設定できません。
wmqJmsClient-1.1 フィーチャーの制約事項
- Windows 環境変数の PATH 変数が IBM MQ インストール済み環境の bin ディレクトリーを指すように手動で設定する必要があります。 アプリケーションが BINDING 接続モードを使用する場合は、この path 変数を設定しなければなりません。
- Java の IBM MQ クラスは、Liberty でサポートされません。 これらは、IBM MQ Liberty メッセージング・フィーチャーおよび汎用 JCA サポートのどちらとも、一緒に使用してはなりません。 詳しくは、『Using WebSphere MQ Java Interfaces in J2EE/JEE Environments』を参照してください。
- wmqJmsClient-1.1 フィーチャーに対しては BINDINGS_THEN_CLIENT トランスポート・タイプ の IBM MQ リソース・アダプターはサポートされていません。
- wmqJmsClient-1.1 フィーチャーに対しては Advanced Messaging Security (AMS) フィーチャー は組み込まれていません。
wmqJmsClient-2.0 フィーチャーの制約事項
- Windows 環境変数の PATH 変数が IBM MQ インストール済み環境の bin ディレクトリーを指すように手動で設定する必要があります。 アプリケーションが BINDING 接続モードを使用する場合は、この path 変数を設定しなければなりません。
- Java の IBM MQ クラスは、Liberty でサポートされません。 これらは、IBM MQ Liberty メッセージング・フィーチャーおよび汎用 JCA サポートのどちらとも、一緒に使用してはなりません。 詳しくは、『Using WebSphere MQ Java Interfaces in J2EE/JEE Environments』を参照してください。
- wmqJmsClient-2.0 フィーチャーに対しては BINDINGS_THEN_CLIENT トランスポート・タイプ の IBM MQ リソース・アダプターはサポートされていません。
collectiveController-1.0 フィーチャーの制約事項
集合コントローラー・サーバーを開始してから IP 構成を変更すると、コントローラーは正しく機能しなくなります。
jpa-2.1 フィーチャーの制約事項
- 代替の JPA 2.1 プロバイダーは使用できません。2.1 サポートが必要な場合は、組み込みプロバイダーを使用する必要があります。
- EclipseLink 固有のフィーチャーまたはアノテーションをアプリケーションで使用することはできません。javax.persistence API のみを使用できます。
concurrent-1.0 フィーチャーの制約事項
concurrent-1.0 フィーチャーでは、以下の制約事項が適用されます。
タイプが securityContext のスレッド・コンテキストで、JAAS ログイン・モジュールを使用して追加されていないサブジェクト内のカスタム情報は、伝搬されません。例えば、TAI によって追加されたカスタム・プリンシパルが送信者のサブジェクトに含まれている場合、伝搬されるサブジェクトに、このカスタム・プリンシパルは含まれません。
sipServlet-1.1 フィーチャーの制約事項
- Performance Monitoring Infrastructure (PMI) の SIP カウンターはサポートされません。
- SIP ダイジェスト認証および JSR 289 セクション 17 のセキュリティー・セクションはサポートされません。
- クラスター化および SIP ダイアログ・パーシスタンスはサポートされません。
jacc-1.5 フィーチャーの制約事項
- アプリケーションの EAR ファイルの ibm-application-bnd.xml ファイルまたは ibm-application-bnd.xmi ファイルに含まれている許可情報 (authorizations 属性の users 属性および groups 属性)。
- server.xml ファイル内の許可情報 (application-bnd エレメント内の security-role 属性の user、group、および special-subject の各属性)。