ランタイム環境での既知の問題および制約事項

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

For distributed platforms

Developer Tools の既知の制約事項も参照してください。

リリース情報

オペレーティング・システムにリリース情報が存在しない場合は、リンクをクリックすると、リリース情報が見つからなかった旨を示すページが表示されます。

既知の問題および制約事項のリスト:

Java の最小サポート・レベル

Liberty は、以下の特定の実装環境について示されている最小サポート・レベルを条件として、準拠するすべての Java™ SE 7 または Java SE 8 ランタイム環境 (JRE)、または Java SDK でサポートされます。[17.0.0.3 and later]
Java SE 6 ランタイム環境
[17.0.0.3 and later]重要: WebSphere Liberty での Java SE 6 の使用に対するサポートは、2017 年 9 月に終了しました。Liberty カーネルは 17.0.0.3 で再コンパイルされました。17.0.0.3 以降、Java SE 6 を使用して Liberty カーネルを実行することはできなくなりました。サポート終了日より後に、旧リリースで Java SE 6 を使用し続けると、環境がセキュリティー・リスクにさらされる可能性があります。

Java SE 8 は、最新の機能とセキュリティー更新を備えているため、これが推奨 Java SDK となります。Java SE 8 をインストールする代わりに、サポートされている別の Java SDK バージョンをインストールできます。

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 です。
重要: フィックスパック 19.0.0.3 以降、Liberty カーネルは Java SE 7 で実行できなくなりました。詳しくは、削除通知を参照してください。
Java SE 8 ランタイム環境
IBM の Java SDK の場合、サポートされる最小レベルは IBM SDK, Java Technology Edition バージョン 8 です。Oracle の JDK の場合、サポートされる最小レベルは Java 8 Update 25 です。

For distributed platforms分散プラットフォームでは、32 ビットまたは 64 ビットの Java がサポートされます。For z/OS platformsz/OS プラットフォームでは、64 ビットの Java のみがサポートされます。

For distributed platformsWindows システムおよび Linux システムでは、 Oracle の JDK または IBM の Java SDK のいずれかを使用することができます。Windows または Linux でアプリケーションを開発していて、WebSphere Application Server traditional で稼働するサーバーにそれらのアプリケーションをデプロイする予定の場合は、 IBM の Java SDK を使用してください。HP システムおよび Mac OS では、Oracle の JDK を使用してください。For z/OS platformsz/OS システムの場合、IBM の Java SDK を使用してください。

For IBM i platforms[17.0.0.3 and later]IBM i V7R1 の場合、最小 JDK レベルは IBM Java SE 7.0 32 ビット JVM (5761JV1 オプション 14) または IBM Java SE 7.0 64 ビット JVM (5761JV1 オプション 15) です。 IBM i V7R2 および V7R3 の場合、最小 JDK レベルは IBM Java SE 7.0 32 ビット JVM (5770JV1 オプション 14) または IBM Java SE 7.0 64 ビット JVM (5770JV1 オプション 15) です。

インストール・ディレクトリー名およびパスに 非 ASCII 文字は使用できない

最近の JVM は、-jar コマンドおよび -javaagent コマンドでの非 ASCII 文字の使用を完全にはサポートしていません。 インストール・ディレクトリー名およびパスには ASCII 文字のみを使用してください。

実行時に JDBC データ・ソースを変更すると、JPA で障害が発生することがある

データベース・ディクショナリー・タイプがプロパティーで指定されない場合、最初のエンティティー・マネージャーが作成されてデータベース接続が行われたときに、OpenJPA がそのタイプの検出および算出を行います。 このデータベース・ディクショナリー・タイプは、その後作成されるすべてのエンティティー・マネージャーに使用されます。 アプリケーションの実行中に JDBC データ・ソースが変更されると、 エンティティー・マネージャー・ファクトリーはこの変更を検出せずに、新しいデータ・ソースの操作に古いディクショナリーを使用し続けます。 データベースが別のベンダーに変更された場合、これにより障害が発生する可能性があります。

データベースを別のベンダーに変更した場合は、アプリケーションを再始動してください。

dataSource、jdbcDriver、connectionManager、および JDBC ベンダー・プロパティーを実行時に変更すると、JPA で障害が発生する可能性がある

サーバーの稼働中に dataSourcejdbcDriverconnectionManager、または いずれかの JDBC ベンダー・プロパティー・リスト (例えば、properties.db2.jcc または properties.oracle など) の構成を更新すると、 J2CA8040E の障害が発生することがあります。 これらの障害では、複数の dataSource エレメントを単一の connectionManager に関連付けられないことに言及しています。 構成で 1 つの connectionManager だけを dataSource エレメントに関連付けている場合にも、これらの障害は生成されます。

これらのいずれかの JDBC リソースの構成を更新したら、サーバーを再始動してください。

getRealPath で返される結果に依存するアプリケーションは、 WAR ファイルではなく、展開されたアプリケーションとしてデプロイする必要がある

Java EE 仕様では、コンテンツが Web アーカイブ (WAR) ファイルから使用可能になっている場合に、 getRealPath() メソッドが null 値を返すことを規定しています。 WAR ファイルを Liberty にデプロイした時、アーカイブ・ファイルが自動的に解凍されてディレクトリー構造が作成されることはありません。そのため、アプリケーションを開始できないことがあります。getRealPath() で返される結果にアプリケーションが依存する場合には、 アプリケーションを WAR ファイルではなく、展開された Web アプリケーションとしてデプロイする必要があります。 例えば、手動で WAR ファイルを解凍して、展開されたアプリケーションを dropins ディレクトリーにコピーすることができます。

WebSphere Application Server traditional のスクリプトは Liberty で動作しない

WebSphere Application Server traditionalbin ディレクトリーの下にあるどのスクリプトも Liberty を管理するために使用できません。

fileset の制約事項

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"/>
For Windows platforms

共有ライブラリーを非公開にしたとき、サーバーが停止するまでそれを削除できない

サーバーから共有ライブラリーを非公開にした場合、ライブラリー JAR ファイルはサーバーから即時に解放されません。 したがって、オペレーティング・システムは、そのファイルがもう使用されていないことを認識しておらず、そのファイルの削除を許可しません。次にサーバーを停止すると、ライブラリー JAR ファイルが解放され、ファイルを削除できるようになります。

For z/OS platforms

特定のトレース・グループに対してサーバー・トレースを有効にするには z/OS APAR OA37620 が必要

個々のトレース・グループをトレースする場合、z/OS APAR OA37620 を適用してください。z/OS プラットフォーム上の Liberty でトレースを有効にする場合は、IBM サポートから別の指示がない限り、パッケージ/クラス構文 (つまり、com.ibm.ws.*=all) を使用してください。

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 の間のバージョン互換性情報について詳しくは、WebSphereMQ リソース・アダプターを入手するための参照資料を参照してください。

汎用 JCA サポートを使用する場合、以下の制約事項が適用されます。
  • 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 ディレクトリーの使用はお勧めできません。

集合フィーチャー、動的ルーティング・フィーチャー、およびスケーリング・フィーチャーを cdi-1.2 フィーチャーと一緒に使用することはできません。

collectiveController-1.0 フィーチャー、collectiveMember-1.0 フィーチャー、 clusterMember-1.0 フィーチャー、dynamicRouting-1.0 フィーチャー、scalingController-1.0 フィーチャー、または scalingMember-1.0 フィーチャーを Contexts and Dependency Injection 1.2 (cdi-1.2) フィーチャーと一緒に使用しないでください。

共有セッション・アプリケーションは、セッション・オブジェクトを共有ライブラリーに保管しなければならない

shared-session-context アプリケーション拡張機能、つまり ibm-application-ext.xml<shared-session-context value="true"/> を使用する場合、 セッションで保管されるオブジェクトはすべて、そのセッションを無効にできるように、アプリケーションに関連付けられた共有ライブラリーで入手可能でなければなりません。

セッション・パーシスタンスの構成

EAR または WAR ファイルごとに server.xml ファイルがあるのではなく、サーバーごとに 1 つのみの server.xml ファイルがあります。以下を追加することによって、データベースにセッション・パーシスタンスを設定します。

<httpSessionDatabase id="SessionDB" dataSourceRef="SessionDS" ... /> 

Liberty では、データベースに対するこの設定はすべての EAR ファイルおよび WAR ファイルに適用されます。一部のデータベースをセッション・パーシスタンスありにし、他のデータベースをセッション・パーシスタンスなしにしてセットアップすることはできません。

移植された、ローカルにトランザクション処理される JMS セッションは、Liberty では機能しない

WebSphere Application Server traditional では、ローカルにトランザクション処理される JMS セッションを活用するアプリケーションを開発できます。そのようなアプリケーションを Liberty に移植すると、アプリケーションは異なる動作をするか、まったく機能しません。

WebSphere Application Server traditional は、ローカルにトランザクション処理される JMS セッションを許可しますが、WebSphere Application Server traditional のローカルにトランザクション処理される JMS セッションを Liberty に移植することは許可されません。

Liberty による IBM MQ メッセージングの使用

LibertyIBM MQ をメッセージング・プロバイダーとして使用している場合、JMS 接続プールの空き接続の再使用基準は、WebSphere Application Server traditional での再使用基準とは異なります。具体的には、 JMS アプリケーションが接続ファクトリー用にコンテナー認証を使用し、数人の認証済みユーザーが同じ接続プールを使用する場合、 Liberty の再使用率は、WebSphere Application Server traditional の再使用率よりも大幅に小さくなります。Liberty の再使用率が低い理由は、 Liberty では、ある認証済みユーザーによって作成された空き接続を他の認証済みユーザーが使用できず、その結果として接続の再生成が頻繁に起こる可能性があることです。Liberty の再使用率がパフォーマンス要件を満たさない場合、properties.wmqJms 内の username プロパティーおよび password プロパティーでのアプリケーション認証を使用できます。

[17.0.0.3 and later]

IBM Cloud Private で実行される Liberty アプリケーション

Liberty アプリケーションを IBM Cloud Private にデプロイする場合、以下の制限があります。
  • 自動スケーリングは、カスタム・メトリックではなく、CPU 使用量のみに基づいています。
  • Ingress は、単一コンテキスト・ルートなどの基本的な構成とアノテーションのみをサポートします。
  • HTTP プロトコルで Ingress を使用するアプリケーションにアクセスするときに、問題が起こることがあります。http://proxy_host/ にあるアプリケーションにアクセスすると、ポート 80 にリダイレクトされますが、これは正しくなく、そのアプリケーションにアクセスすることはできません。この問題を修正するには、URL からポート 80 を削除します。
  • 現在、Liberty Helm chart は、単一レプリカのトランザクション・ログの永続性のみをサポートします。
[18.0.0.1 and later]

JSON ロギングの制約事項

JSON ロギングの使用には、以下の制約事項が適用されます。
  • バイナリー・ロギングが構成されている場合、コンソールに書き込まれるログ・レコードは、JSON ロギングが有効になっていても基本フォーマットのままになります。
  • JSON ロギングが z/OS 上で有効になっている場合、サーバー始動期間に一部のメッセージが欠落する可能性があります。
  • JSON ロギングが有効になっている場合、System.out/err に記録されるスロー可能な例外は [internal classes] で切り捨てられません。

Admin Center フィーチャーの制約事項

adminCenter-1.0 フィーチャーには次の制約があります。
  • WebSphere Application Server Network Deployment Liberty などの WebSphere Application Server traditional 製品で使用可能な IBM Java 仮想マシン (JVM) を使用すると、Liberty Administrative Center (「Admin Center」) がブラウザーに表示されないことがあります。デフォルトでは、WebSphere Application Server traditional 製品で使用可能な IBM JVM は、 Secure Sockets Layer (SSL) を必要とする Admin Center で必要なセキュリティー・クラスではなく、WebSphere Application Server traditional 製品でのみ使用可能なセキュリティー・クラスを指します。Liberty 製品と SSL をサポートする JVM を使用してください。
    以下のように、Installation Manager オファリングまたは developerWorks® から、Liberty 製品および SSL をサポートする JVM を入手できます。
    • Installation Manager を使用して、まず Liberty 製品を選択してから、WebSphere SDK for Liberty を選択します。Installation Manager を使用して、Liberty 製品および Software Development Kit (SDK) をインストールします。WebSphere SDK for Liberty には、Liberty 製品と SSL に必要なサポートが含まれており、また Java クライアント JConsole が用意されています。
    • developerWorks Web サイトの http://www.ibm.com/developerworks/java/jdk/index.html にアクセスし、ご使用のオペレーティング・システム用の IBM Java Development Kit (JDK) をダウンロードします。developerWorks Web サイトでは、すべてのオペレーティング・システム用の JVM が用意されているわけではありません。例えば、Windows オペレーティング・システムの場合、Eclipse から JDK を入手する必要があります。
  • Admin Center モニター・ビューの CPU 使用率グラフでは、プロセス CPU 統計を提供しない JVM に対して、0% の CPU 使用率が表示されます。グラフについて詳しくは、Admin Center でのメトリックのモニターを参照してください。
[16.0.0.4 and later]Java バッチ・ツールには、以下の制限が適用されます。
  • バッチ・ジョブまたはジョブ・ログを持つ各リモート・サーバーに CORS 構成がある場合を除き、リモート・マシンからのジョブ・ログは表示できません。Admin Center での Java バッチ・ジョブの表示を参照してください。
  • インスタンス・ログが表示され、複数のホストにわたって実行される場合は、エラーが予想されます。
  • Java バッチ・ツールでは、batchManagement-1.0 フィーチャーを指定して永続データベースを使用する必要があります。

appClient-1.0 フィーチャーの制約事項

appClient-1.0 フィーチャーには次の制約があります。
  • このフィーチャーは Java EE アプリケーション・クライアントをサポートしていません。起動できるのはスタンドアロン・クライアント・プログラムのみです。

appSecurity-2.0 フィーチャーの制約事項

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 検証フィーチャーの制約事項

beanvalidation-1.0 フィーチャーには次の制約があります。
  • OSGi アプリケーション内の Bean 検証はサポートされません。
beanValidation-1.1 フィーチャーには次の制約があります。
  • 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

collectiveController-1.0 フィーチャーの制約事項

集合コントローラー・サーバーを開始してから IP 構成を変更すると、コントローラーは正しく機能しなくなります。

concurrent-1.0 フィーチャーの制約事項

concurrent-1.0 フィーチャーでは、以下の制約事項が適用されます。

タイプが securityContext のスレッド・コンテキストで、JAAS ログイン・モジュールを使用して追加されたのではないサブジェクト内のカスタム情報は、伝搬されません。例えば、TAI によって追加されたカスタム・プリンシパルが送信者のサブジェクトに含まれている場合、伝搬されるサブジェクトに、このカスタム・プリンシパルは含まれません。

動的キャッシュ・フィーチャーの制約事項

以下の動的キャッシュ・フィーチャーは使用できないか、使用に制限があります。
  • キャッシュ複製はサポートされません。
  • ハイパフォーマンスのディスク・キャッシング・モードのみが、ランダムおよびサイズ・ベースの排除技法によってサポートされます。
  • Web サービス・クライアント・サイドとサーバー・サイドのキャッシングおよび cachespec.xml ファイル内のポートレット・キャッシュはサポートされません。
  • SingleThreadModel サーブレットのサーブレット・キャッシングはサポートされません。
  • プロパティー・ファイルを使用したキャッシュ構成の定義は、Enterprise JavaBeans (EJB) のみを含む JAR ファイルではサポートされません。
  • ヒープ・キャッシュ・サイズの制限は 32 ビットの Java 仮想マシン (JVM) でのみ有効です。

Enterprise JavaBeans (EJB) フィーチャーの制約事項

以下の制約事項は、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 コンポーネントでイベント通知リスナーを登録できません。

jacc-1.5 フィーチャーの制約事項

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 の各属性)。

jaxb-2.2 フィーチャーの制約事項

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 フィーチャーの制約事項

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 フィーチャーには次の制約があります。
  • jsf-2.2 フィーチャーを faces-config.xml ファイルと一緒に使用して、バージョン 2.2 および名前空間を指定すると、エラーが発生します。
  • jsf-2.2cdi-1.2ejb-3.2、および jpa-2.1 と共に有効にすると、フィーチャーの競合が発生します。

jsp-2.2 フィーチャーの制約事項

jsp-2.2 フィーチャーには次の制約があります。
  • 変換された JSP ファイルをメモリーにのみ保管する useInMemory 構成オプションのサポートはありません。

jpa-2.1 フィーチャーの制約事項

jpa-2.1 フィーチャーには次の制約があります。
  • 代替の JPA 2.1 プロバイダーは使用できません。2.1 サポートが必要な場合は、組み込みプロバイダーを使用する必要があります。
  • EclipseLink 固有のフィーチャーまたはアノテーションをアプリケーションで使用することはできません。javax.persistence API のみを使用できます。

logstashCollector-1.0 フィーチャーの制約事項

logstashCollector-1.0 フィーチャーには、以下の制約事項が適用されます。
  • データ損失 – Liberty で生成されたイベントの一部が、予期どおりに Logstash に転送されない場合があります。 データ損失は、以下のシナリオで発生する可能性があります。
    1. Logstash サーバーが始動される前に Liberty サーバーを始動。 Logstash サーバーを始動してから Liberty サーバーを始動することをお勧めします。
    2. 重負荷条件。 Liberty イベント・パイプライン、Logstash、およびその他のダウンストリームのコンシューマーがイベントを処理可能な速度を超えて、Liberty でイベントが作成されるケースでは、 イベントがドロップされる可能性があります。イベント作成がイベント消費より一時的に速い場合、Liberty はバッファーを使用してデータ損失を回避します。
  • logstashCollector-1.0 フィーチャーは、Logstash V2.x および Logstash V5.x でテストされ、これらと互換性があります。

monitor-1.0 フィーチャーの制約事項

monitor-1.0 フィーチャーには次の制約があります。
  • このフィーチャーが server.xml ファイルから 削除される場合、JAX-WS アプリケーションが機能するようサーバーを再始動する必要があります。
[17.0.0.3 and later]

openapi-3.0 フィーチャーの制約事項

openapi-3.0 フィーチャーには次の制約があります。

  • apiDiscovery-1.0 とは異なり、openapi-3.0 は、現在のところ Try it out! フィーチャーをサポートしていません。
  • http://Liberty_host:http_port/api/docshttps://Liberty_host:https_port/api/docs、または https://Liberty_host:https_port/ibm/api/docs のいずれかにある文書を Microsoft Internet Explorer 11 で表示すると、正しくフォーマットされていない YAML 文書が返されます。回避策として、Mozilla Firefox または Google Chrome ブラウザーなどのブラウザーを使用してください。
  • openapi-3.0 は、複数の言語用の OASProvider 構成をサポートしません。結果を 1 つだけ返すプロバイダーを指定してください。
  • 現在、JAX-RS アノテーションおよび OpenAPI アノテーションのすべてがサポートされているわけではありません。
  • サーバー稼働中に検証属性の値が変更された場合、以前にロードされたアプリケーションは、新しい検証設定がアプリケーションに対して有効になるように、再始動される必要があります。
  • OpenAPI 文書の以下の部分は検証されません。
    • component
    • discriminator
    • エンコード
    • extension
    • header
    • リンク
    • schema
    • 有効範囲
    • xml

requestTiming-1.0 フィーチャーの制約事項

requestTiming-1.0 フィーチャーには次の制約があります。
  • requestTiming-1.0 フィーチャーは、アクティブ化されている場合、DayTrader アプリケーションで測定すると、最大可能アプリケーション・スループットに 4% の悪影響を与えることが分かっています。ご使用のアプリケーションへの影響ではこの数値が前後する可能性がありますが、パフォーマンスの低下が顕著になる可能性があることに留意する必要があります。

restConnector-1.0 フィーチャーの制約事項

restConnector-1.0 フィーチャーには次の制約があります。

  • restConnector-1.0 フィーチャー、または restConnector-1.0 を含む任意のフィーチャー (collectiveMember-1.0collectiveController-1.0 など) のユーザーがカスタム JAXRS 2.0 ランタイムを含むアプリケーションを実行する場合、jaxrs-2.0 フィーチャーをそのサーバーに追加する必要があります。

scim-1.0 フィーチャーの制約事項

scim-1.0 フィーチャーには、以下の制約事項が適用されます。
  • groups を検索しているときに members 属性は取得されません。
  • users を検索しているときに usersgroups 属性は取得されません。
  • usersgroups 属性に direct/indirect の正規タイプは設定できません。
  • 正規タイプ work のユーザーの email 属性は、1 つだけ定義可能です。
  • 正規タイプ work のユーザーの ims 属性は、1 つだけ定義可能です。
  • entitlementsrolesx509Certificates などの、SCIM の拡張スキーマ属性は、設定することも、戻すこともできません。
  • userName 属性をフィルター内で他の属性と一緒に使用することはできません。
  • 基本レジストリーと SAF レジストリーのユーザーには、userNamedisplayNameidschemameta.location、および groups のみを設定できます。userName と displayName は、同じ値になります。
  • 基本レジストリーおよび SAF レジストリーによるリスト/照会の動作は、ldapRegistry レジストリーと同じではありません。
  • prgtgeltleandor、および () などの演算子は、基本レジストリーおよび SAF レジストリーで動作しません。また、基本レジストリーおよび SAF レジストリーには、フィルターで 1 つの演算子だけを使用する必要があります。
  • 基本と SAF は読み取り専用レジストリーです。
  • user を作成しているときに、groups 属性は設定できません。

sipServlet-1.1 フィーチャーの制約事項

sipServlet-1.1 フィーチャーの場合、以下の制約が Session Initiation Protocol (SIP) サポートに適用されます。
  • Performance Monitoring Infrastructure (PMI) の SIP カウンターはサポートされません。
  • SIP ダイジェスト認証および JSR 289 セクション 17 のセキュリティー・セクションはサポートされません。
  • クラスター化および SIP ダイアログ・パーシスタンスはサポートされません。

socialLogin-1.0 フィーチャーの制約事項

socialLogin-1.0 フィーチャーには次の制約があります。
  • socialLogin-1.0 の場合、Windows Server 2012 オペレーティング・システム上の Internet Explorer ではデフォルト・ソーシャル・メディア選択フォームが正常に機能しない可能性があります。プロバイダーが選択され、フォームがサブミットされるときに、Internet Explorer は、表示されたボタンに対して構成された HTML 値ではなく、そのボタンのテキストをデフォルト値として送信する可能性があります。この制約事項を回避するには、異なる Web ブラウザーを使用します。Internet Explorer 以外のブラウザーでは、デフォルト選択フォームは正しく機能します。

wmqJmsClient-1.1 フィーチャーの制約事項

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 フィーチャーの制約事項

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 リソース・アダプターはサポートされていません。

トピックのタイプを示すアイコン 参照トピック

ファイル名: rwlp_restrict.html