Open Liberty 23.0.0.2でのデータベース接続のテストとサーバー停止タイムアウトの設定
Open Liberty 23.0.0.2 では、Admin Center Server Config ツールでデータベース接続をテストする新しいフィーチャーが導入されました。server stopコマンドに、サーバーが停止するまでの最大待機時間を指定するための-timeoutオプションが追加されました。このリリースでは、Jakarta RESTful Web Services 3.0フィーチャーのCVEに対処したものを含む、多くの重要なバグ修正も提供します。
In Open Liberty 23.0.0.2:
ランタイムに追加された新フィーチャーと一緒にガイドの更新を作成しました。
修正された主なバグリストは23.0.0.2からご確認いただけます。
Open Liberty GAのリリースブログの記事もご確認ください
23.0.0.2を使ってアプリを実行する
Mavenを使う時には下記の設定をお使いください。
<dependency>
<groupId>io.openliberty</groupId>
<artifactId>openliberty-runtime</artifactId>
<version>23.0.0.2</version>
<type>zip</type>
</dependency>
Gradleの場合はこちらです。
dependencies {
libertyRuntime group: 'io.openliberty', name: 'openliberty-runtime', version: '[23.0.0.2,)'
}
Dockerの場合はこちらです。
FROM open-liberty
またはダウンロード・ページをご参照ください。
Admin Centerを使用してデータベース接続をテストする
データベース接続をテストする簡単な方法をお探しですか?このリリースでは、Liberty Admin Centerのフィーチャーを使用して、接続を検証できるようになりました。接続テストは、アプリケーションと同じコードパスを実行するため、サーバー構成に確信を持つことができます。Admin Centerの接続検証フィーチャーはREST APIsによるOpen Libertyアプリのデータベース接続テストで紹介した同じREST APIsで有効です。
データベース接続テストを有効にするには、サーバー構成に以下の最低限必要なフィーチャーのセットを用意する必要があります。
<feature>adminCenter-1.0</feature>
<feature>restConnector-2.0</feature>
<feature>mpOpenApi-3.0</feature>
この例では mpOpenApi-3.0
フィーチャーを使用していますが、他のフィーチャーと互換性のある任意の MicroProfile OpenAPI バージョンを使用することができます。
例として、まずサーバーリソース DefaultDataSource
をテストします。このリソースは、認証エイリアスを使用したコンテナ認証を使用してDerbyデータベースに接続するように構成されています。
以下のサンプル server.xml
ファイルは、Admin Center のテスト接続フィーチャーを設定し、Derby データベースへの接続を設定するフィーチャーを有効にします。
<server description="new server">
<!-- Enable features -->
<featureManager>
<feature>adminCenter-1.0</feature>
<feature>restConnector-2.0</feature>
<feature>jdbc-4.3</feature>
<feature>mpOpenApi-3.0</feature>
</featureManager>
<!--リモートクライアントからこのサーバーにアクセスするには、次の要素にhost属性を追加してください 例:host="*" -->
<httpEndpoint id="defaultHttpEndpoint" httpPort="9080" httpsPort="9443"/>
<library id="derby">
<file name="${server.config.dir}/derby/derby.jar"/>
</library>
<dataSource id="DefaultDataSource">
<jdbcDriver libraryRef="derby"/>
<!-- インメモリDerby Embeddedデータベースを参照するプロパティ例 -->
<properties.derby.embedded databaseName="memory:defaultdb" createDatabase="create"/>
</dataSource>
<authData id="myAuth" user="dbuser" password="dbpass"/>
<!-- デフォルトのSSL設定により、Javaランタイムのデフォルト証明書を信頼することが可能 -->
<ssl id="defaultSSLConfig" trustDefaultCerts="true"/>
<remoteFileAccess>
<writeDir>${server.config.dir}</writeDir>
</remoteFileAccess>
<basicRegistry id="basic">
<user name="admin" password="adminpwd"/>
</basicRegistry>
<!-- 管理者に「admin」を割り当てる -->
<administrator-role>
<user>admin</user>
</administrator-role>
</server>
この server.xml
の例では、Derby JAR をサーバー設定に追加するか、独自のデータベース設定を使用する必要があります。
-
サンプルの
server.xml
ファイルを参考に Liberty サーバを設定し、サーバを起動します。サーバーが起動したら、ログを確認して、Admin Center に移動するための URL を見つけることができます。前の例では、https://localhost:9443/adminCenter/
URL を使用して Admin Center に移動することができます。 -
Admin Center UI で、Server Config ツールを選択します。
-
編集する server.xml を選択します。
-
Design > Server メニューで、テストしたいリソースに移動し、Test** ボタンをクリックします。
-
アプリケーションが使用する認証の種類を選択します。
-
コンテナ認証を使用するアプリケーションでは、コンテナ認証タブを選択し、デフォルト認証を使用するか、認証エイリアスを指定するか、ログインモジュール構成を選択するかを選択します。
この例では、`dataSource`要素にデフォルトの認証を指定したり、ログインモジュールを設定するような構成にはなっていません。したがって、ドロップダウン・フィールドを使用して認証エイリアスを指定する必要があります。
-
アプリケーション認証を使用するアプリケーションでは、アプリケーション認証タブを選択し、データベースリソースの有効なユーザー名とパスワードを入力します。
-
アプリケーションがリソース参照を使用しない場合、
server.xml
のconnectionManager
elementを選択し、No resource referenceタブを選択し、データベースリソースの有効なユーザー名とパスワードを入力します。
-
-
Connection Testボタンをクリックすると、テストが実行され、結果が表示されます。 次の例は、接続テストに成功した例です。
さらにJava Database Connectivityに加えて、Jakartaコネクター, JakartaメッセージングとCloudant Integrationリソースへのテスト接続も可能です。
GUIによるLibertyの管理については、Admin CenterでOpen Libertyを管理するドキュメントをご参照ください。
サーバーが停止するまでの待ち時間を指定する
Open Liberty 23.0.0.2 では、server stop
コマンドに --timeout
コマンドラインオプションが追加されました。 このオプションを使用すると、server stop
コマンドがサーバーが停止したことを確認するために待機する最大時間を指定することができます。
今回のアップデート以前は、デフォルトの最大待機時間である30秒を調整することができませんでした。
タイムアウト値は分単位(m
)、秒単位(s
)、またはその両方を組み合わせて指定することができます。 単位が指定されない場合、デフォルトである秒が使用されます。 分と秒は組み合わせることができ、例えば 2m30s
は2分30秒を意味します。
./server stop // 30 seconds
./server stop --timeout=45 // 45 seconds
./server stop --timeout=45s // 45 seconds
./server stop --timeout=3m20s // 3 minutes, 20 seconds
タイムアウト値のデフォルトは30秒です。サーバーの停止に常に30秒以上かかる場合は、-timeoutオプションを使用してタイムアウト値を増やすことを検討してください。
詳細はserver stop commandドキュメントをご参照ください。
本リリースにおけるセキュリティ脆弱性(CVE)修正
CVE | CVSSスコア | 脆弱性評価 | 影響を受けるバージョン | ノート |
---|---|---|---|---|
5.5 |
Information disclosure |
21.0.0.12 - 23.0.0.1 |
restfulWS-3.0 フィーチャーに影響あり |
過去のセキュリティ脆弱性の修正のリストについては、Security vulnerability (CVE) listをご参照ください。
主なバグ修正
以下のセクションでは、このリリースで修正したバグの一部について説明します。興味がある場合はfull list of bugs fixed in 23.0.0.2をご参照ください。
-
サーブレット・フィーチャーの競合により、サーバーの起動に失敗する
featureUtility installFeature
コマンドでEE7またはEE8の機能セットを個別にインストールする場合、以下の例のようにサーブレット・フィーチャーでの競合によりサーバー起動できない場合があります。com.ibm.ws.kernel.feature.internal.FeatureManager E CWWKF0033E: The singleton features servlet-3.1 and servlet-3.0 cannot be loaded at the same time. The configured features servlet-3.1 and apiDiscovery-1.0 include one or more features that cause the conflict. Your configuration is not supported; update server.xml to remove incompatible features. com.ibm.ws.logging.internal.impl.IncidentImpl I FFDC1015I: An FFDC Incident has been created: "java.lang.IllegalArgumentException: Unable to load conflicting versions of features "com.ibm.websphere.appserver.servlet-3.1" and "com.ibm.websphere.appserver.servlet-3.0". The feature dependency chains that led to the conflict are: com.ibm.websphere.appserver.servlet-3.1 and com.ibm.websphere.appserver.apiDiscovery-1.0 -> com.ibm.websphere.appserver.restHandler-1.0 -> io.openliberty.restHandler.internal-1.0 -> io.openliberty.webBundleSecurity.internal-1.0 -> io.openliberty.servlet.internal-3.0 -> com.ibm.websphere.appserver.servlet-3.0
代わりに
featureUtility installServerFeatures
コマンドを使用するとこの問題は発生しません。また、Jakarta EE 8の機能を使用する場合は、`mpJwt-1.2`フィーチャーをインストールすることで回避することができます。この問題は解決され、`featureUtility installFeature`コマンドは、すべての機能を`server.xml`に含めることができるようにインストールし、サーバーを正しく起動することができるようになりました。
-
アプリケーション停止時にManaged Executor ServicesからScheduled Futuresがリソースをリークする
ManagedScheduledExecutorServiceImpl`の`futures`キューは、スケジュールされたフューチャーの参照を保持し、それが完了した後でも保持します。
キューは、新しいタスクがスケジュールされると、プライベートな
purgeFutures()
メソッドによって定期的にクリーニングされますが、それ以外は積極的に削除されることはありませんし、アプリケーションがシャットダウンしたときにも呼ばれません。purgeFutures()`はプライベートなので、アプリケーションが自分自身で呼び出すことはできません。この問題は解決され、アプリケーションの停止時にリソースが自動的に解放されるようになりました。
-
バグにより、HTTPリクエストで無効な文字がないかチェックされていませんでした。
この問題は解決され、無効な文字を含むHTTPリクエストは、HTTPレスポンスに`400`レスポンスコードが含まれるようになりました。
-
DoNotAllowDuplicateSetCookies httpチャネル設定オプションが動作しない
HTTPチャネルの設定プロパティ
DoNotAllowDuplicateSetCookies=true
を設定しても、HTTPレスポンスで重複したSet-Cookie
クッキーを許可します。この問題は解決され、DoNotAllowDuplicateSetCookies=true`が設定されている場合、レスポンスヘッダーには重複した
Set-Cookie
のクッキーが含まれないようになりました。 -
batch-1.0、2.0を設定してもbatch-2.1の機能コンテンツは有効です
ベータ版の
batch-2.1
機能の一部として追加されたコンテンツは、ユーザーがbatch-1.0
もしくはbatch-2.0
としてサーバーを設定しても読み込まれて有効になります。これは意図的ではなく、ユーザーの環境に応じてコンフリクトが発生する可能性があります。この問題は解決され、新しい
batch-2.1
固有のコンテンツはbatch-1.0
やbatch-2.0
の機能で公開されなくなりました。 -
CWWKS1738Eメッセージで使用されるコンフィギュレーション属性名を修正
ソーシャルメディア・ログイン・フィーチャー経由でOIDC RPを使用する場合、OPから返されたIDトークンに期待したユーザー名の項目がない場合に、誤ったコンフィギュレーション属性名を含むエラーメッセージが出てしまう可能性があります。以下は、そのようなエラーメッセージの例です。
.ws.security.openidconnect.clients.common.AttributeToSubject E CWWKS1738E: The OpenID Connect client [client01] failed to authenticate the JSON Web Token because the claim [someBadName] specified by the [userIdentifier] configuration attribute was not included in the token.
エラーメッセージは
userIdentifier
というコンフィグレーション属性に言及しています。しかし、`socialLogin-1.0`の機能では、同等のコンフィグレーション属性は実際には`userNameAttribute`と呼ばれます。この問題は、正しい属性名を参照するようにNLSメッセージを更新することで解決されました。
前回のリリース以降の新しいガイドと更新されたガイド
Open Libertyの特徴や機能が増え続ける中、できるだけ簡単に導入できるように、それらのトピックに関するopenliberty.ioへの新しいガイドを追加しています。既存のガイドも、報告されたバグや問題に対処し、内容を最新に保ち、トピックの内容を拡張するために更新されます。
-
gRPCを使ったクライアントとサーバーのサービス間のメッセージストリーミング
-
この度発行されたガイドのクラウドホスト版が公開されました。
-