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

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

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

一般的な制約事項:

Liberty フィーチャーに固有の制約事項:

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

Liberty は、準拠するすべての Java™ SE 8、11、17、21、または 22 ランタイム環境 (JRE) または Java SDK によってサポートされ、以下の特定の実装で示される最小サポート・レベルに従います。

重要: z/OS® プラットフォームは、Java SE 8、Java SE 11、および Java SE 17 のみをサポートします。 Java SE 21 および Java SE 22 は、 z/OSではサポートされていません。

Java SE 8 ランタイム環境: IBM®の Java SDK の場合、サポートされる最小レベルは IBM SDK, Java Technology Edition バージョン 8 です。 Oracleの JDK の場合、サポートされる最小レベルは Java 8 Update 25 です。

z/OS プラットフォームでは、64 ビット Java のみがサポートされます。

z/OS システムの場合は、 IBMの Java SDK を使用します。

Java SE 11 ランタイム環境: IBM Semeru Runtimes for Java™ 11 を使用する Java SE 11 での実行がサポートされます。サポートされている最小限のレベルは Java バージョン 11.0.2 です。 Java SE 8 と Java SE 11 の間で Java SE プラットフォームの大幅な変更が行われたため、ゼロ・マイグレーションは保証されないことに注意してください。

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

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

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"/>

WebSphere MQ リソース・アダプターおよび汎用 JCA サポートに関連した制約事項

WebSphere® MQ リソース・アダプターは、 wmqJmsClient-1.1 または wmqJmsClient-2.0 フィーチャーを使用するか、汎用 JCA サポートを使用して、 WebSphere Application Server Liberty 内で使用できます。

WebSphere MQ リソース・アダプターのバージョン 7.5 を Liberty バージョン 8.5.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の間のバージョン互換性情報について詳しくは、「 Reference to obtain WebSphere MQ リソース・アダプター」を参照してください。

汎用 JCA サポートを使用する場合、以下の制約事項が適用されます。

IBM WebSphere MQ リソース・アダプターを z/OS上で実行するには、 wmqJmsClient-1.1 または wmqJmsClient-2.0 フィーチャーを使用する必要があります。
トレースおよびロギングは、汎用 JCA を使用して Liberty トレース・システム内に統合されることはありません。トレースは別のファイルに書き込まれ、システム・プロパティーを設定して使用可能にする必要があります。トレースを使用可能にする手順は、 WebSphere MQ classes for JMS トレース機能を Java 標準環境用に構成するのと同じです。 Java 標準環境トレース・スタンザを参照してください。
IBM MQ classes for Java は、 Libertyではサポートされません。これらは、 IBM MQ Liberty メッセージング・フィーチャーまたは汎用 JCA サポートのいずれとも一緒に使用してはなりません。詳しくは、 Using WebSphere MQ Java Interfaces in J2EE/JEE Environmentsを参照してください。

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

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

共有セッション・アプリケーションの制約事項

ibm-application-ext.xmlで共有セッション・コンテキスト・アプリケーション拡張機能または <shared-session-context value="true"/> を使用している場合、セッションを無効にするには、セッションに保管されているすべてのオブジェクトが、アプリケーションに関連付けられている共有ライブラリーで使用可能でなければなりません。また、IBMApplicationSession インターフェースを使用する共有セッション・アプリケーションは Liberty ではサポートされていません。

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

Liberty アプリケーションを IBM Cloud® Privateにデプロイする場合、以下の制約事項があります。

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

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

appSecurity フィーチャーには、以下の制約事項が適用されます。

EJB アプリケーションの場合、SYSTEM_IDENTITY の run-as-mode は、 ibm-ejb-jar-ext.xml ファイルの拡張設定ではサポートされません。
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
```

CDI フィーチャーの制約事項

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

@Observes @Initialized(ApplicationScoped.class) アノテーションが付けられたメソッドの内部にある JNDI 検索では、メソッド起動中に使用可能なのは java:app 名前空間のみです。 Liberty 18.0.0.1 以前で、別の名前空間が必要な場合は、クラスを WAR ファイルに移動してください。
この問題を修正するには、Liberty 18.0.0.2 にアップグレードしてください。修正しない場合、クラスを WAR ファイルに移動しない限り、使用可能な名前空間はありません。

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

cdi-2.0 フィーチャーは、最小限 IBM Java レベル 8.0.5.6 を必要とします。この Java バージョンには、ObserverExceptionHandler という名前の Weld インターフェースに対して IllegalAccessException が発生するのを防止する修正が含まれています。

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 フィーチャーに適用されます。

セッション 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 フィーチャーには、以下の制約事項が適用されます。

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 サービス・クライアント・アプリケーションを手動で再始動する必要があります。

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

jpa-2.1 フィーチャーには、以下の制約事項が適用されます。

代替 JPA 2.1 パーシスタンス・プロバイダーを使用する必要がある場合は、代わりに jpaContainer-2.1 フィーチャーを使用してください。
EclipseLink に固有のフィーチャーおよびアノテーションは、サード・パーティー API パッケージとして公開されます。これらを使用可能にするには、サード・パーティーのクラス・ロードに合わせてクラス・ローダーを構成する必要があります。

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

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

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

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

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

フィーチャーが server.xml ファイルから削除された場合、JAX-WS アプリケーションを機能させるには、サーバーを再始動する必要があります。

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

openapi-3.0 フィーチャーには、以下の制約事項が適用されます。

http://Liberty_host:http_port/api/docs、 https://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 文書の以下の部分は検証されません。
- 要件がなくなり、
- discriminator
- encoding
- extension
- 見出し
- link
- schema
- 有効範囲
- XML

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

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

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

代わりに restConnector-2.0 フィーチャーを使用できます。

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

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

groups を検索しているときに members 属性は取得されません。
users を検索しているときに users の groups 属性は取得されません。
direct/indirect の正規タイプは、 usersの groups 属性には設定できません。
正規タイプ 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 属性は設定できません。

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 以外のブラウザーでは、デフォルト選択フォームは正しく機能します。

ssl-1.0 フィーチャーおよび transportSecurity-1.0 フィーチャーの制約事項

ssl-1.0 フィーチャーと transportSecurity-1.0 フィーチャーには、次の制約があります。

Java SE 11 では、新しい TLS プロトコル・バージョン TLSv1.3が導入されました。この新しいプロトコル・バージョンは、既存の Liberty フィーチャーと後方互換性がないため、 TLSv1.3の使用に対応するために Java SE または Liberty (あるいはその両方) のコード変更が行われるまで、グローバルに使用不可になります。 IBM Semeru Runtimes for Java™ 11 以降を使用する場合は、TLSv1.3プロトコルも組み込まれます。 IBM Semeru Runtimes for Java™ 11 での暗号アクセラレーションのための OpenSSL の使用について詳しくは、 Semeru Runtimes セキュリティー・マイグレーション・ガイドを参照してください。
ssl-1.0 フィーチャーが有効になっている場合は、 SSLContext.getDefault() メソッドを使用して Liberty デフォルト SSLContext ・クラスを取得します。ただし、 transportSecurity-1.0 が有効になっている場合、 SSLContext.getDefault() メソッドは Java Secure Socket Extension (JSSE) SSLContext クラスを返します。したがって、一方のフィーチャーから他方のフィーチャーに変更すると、アプリケーション・コードの更新が必要になる場合があります。 transportSecurity-1.0 フィーチャーが有効になっている場合にデフォルトの Liberty SSLContext クラスを取得するには、 SSLContext.getDefault() メソッドの代わりに JSSEHelper.getInstance().getSSLContext(null, null, null) メソッドを使用します。

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

wmqJmsClient-1.1 フィーチャーには、以下の制約事項が適用されます。

Windows 環境変数の PATH 変数が IBM MQ インストール済み環境の bin ディレクトリーを指すように手動で設定する必要があります。アプリケーションが BINDING 接続モードを使用する場合は、この path 変数を設定しなければなりません。
IBM MQ classes for Java は、Liberty ではサポートされません。これらは、 IBM MQ Liberty メッセージング・フィーチャーまたは汎用 JCA サポートのいずれとも一緒に使用してはなりません。詳しくは、 Using WebSphere MQ Java Interfaces in J2EE/JEE Environmentsを参照してください。
IBM MQ リソース・アダプターの BINDINGS_THEN_CLIENT トランスポート・タイプは、 wmqJmsClient-1.1 フィーチャーではサポートされません。
Advanced Messaging Security (AMS) フィーチャーは、 wmqJmsClient-1.1 フィーチャーには組み込まれていません。

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

wmqJmsClient-2.0 フィーチャーには、以下の制約事項が適用されます。

Windows 環境変数の PATH 変数が IBM MQ インストール済み環境の bin ディレクトリーを指すように手動で設定する必要があります。アプリケーションが BINDING 接続モードを使用する場合は、この path 変数を設定しなければなりません。
IBM MQ classes for Java は、Liberty ではサポートされません。これらは、 IBM MQ Liberty メッセージング・フィーチャーまたは汎用 JCA サポートのいずれとも一緒に使用してはなりません。詳しくは、 Using WebSphere MQ Java Interfaces in J2EE/JEE Environmentsを参照してください。
IBM MQ リソース・アダプターの BINDINGS_THEN_CLIENT トランスポート・タイプは、 wmqJmsClient-2.0 フィーチャーではサポートされません。