第3章 機能

Eclipse Vert.x 4.2.7 以降、Eclipse Vert.x は Red Hat OpenJDK 17 での使用が認定されています。

Eclipse Vert.x 4.2.4 以降では、RequestOptions メソッドは HTTP ヘッダーを検証し、ヘッダー名が無効な場合に要求が失敗します。

Eclipse Vert.x の以前のリリースでは、RequestOptions メソッドではヘッダー名を検証しない Multimap 実装が使用されていたため、HTTPClientRequest は HTTP ヘッダーを検証していました。

Eclipse Vert.x 4.2.4 以降では、simple ロケールが MongoDB collation のデフォルトロケールとして使用されます。

Eclipse Vert.x 4.2.3 では、文字列を比較するための言語固有のルールをサポートする照合オプションに対するサポートが導入されました。Eclipse Vert.x 4.2.3 では、プラットフォームのデフォルトがデフォルトのロケールとして使用されていました。ただし、プラットフォームのデフォルトは定数値ではないため、MongoDB でサポートされていないロケールを使用するシステムでエラーが発生する可能性がありました。たとえば、Locale.FR は正常に機能しますが、Locale.FR_FR はサポートされません。

Eclipse Vert.x 4.2.4 以降では、webroot ディレクトリーおよびファイルシステムアクセスの StaticHandler 設定プロパティーは、StaticHandler ファクトリーコンストラクター呼び出しで定義されます。

たとえば、以下のコンストラクター呼び出しは、webroot ディレクトリー、static/resources、および相対ファイルシステムアクセスを定義します。

StaticHandler.create(FileSystemAccess.RELATIVE, "static/resources");

たとえば、以下のコンストラクター呼び出しは、webroot ディレクトリー、/home/paulo/Public、および root ファイルシステムのアクセスを定義します。

StaticHandler.create(FileSystemAccess.ROOT, "/home/paulo/Public");

Eclipse Vert.x の以前のリリースでは、allowRootFileSystemAccess および webroot プロパティーはセッターを使用して定義されていました。ただし、このプロパティーの値は最終的なものではなかったため、無効な静的設定が生じる可能性がありました。Eclipse Vert.x 4.2.4 では、前述のコンストラクター呼び出しは以下のセッター宣言に優先されるようになりました。

StaticHandler.create()
  .setAllowRootFileSystemAccess(true)
  .setWebRoot("/home/paulo/Public");

Eclipse Vert.x 4.2.0 以降では、-1 などの負のポート番号にバインドされた 2 つの異なる HTTP サーバーは、特定の verticle デプロイメントのインスタンス内で同じランダムポートを共有します。つまり、ポート -1 にバインドされている複数の HTTP サーバーが、同じランダムポートを共有します。同様に、ポート -2 にバインドされている複数の HTTP サーバーは、同じランダムポートを共有します。異なる HTTP サーバーが異なるランダムポートを持つことが可能になるため、負のポート番号に基づくこのポート共有の動作は verticle とは無関係です。

Eclipse Vert.x の以前のリリースでは、ランダムサーバーポート共有は、ポート 0 にバインドされた 2 つの HTTP サーバーに基づいていました。しかし、これにより、同じ verticle のインスタンス内に、異なるランダムポートを持つ 2 つの HTTP サーバーをバインドできなくなりました。

Eclipse Vert.x 4.2.0 には、すべてのクッキーを取得できる新しいメソッド Set<Cookie> cookies() が含まれます。

Vert.x の以前のリリースでは、HttpServerRequest および HttpServerResponse インターフェイスは、EclipseVert.x4.2.0 で非推奨となった次のメソッドを使用していました。

Map<String, Cookie> cookieMap()

RFC 6265 - HTTP 状態管理メカニズム の仕様では、各クッキーはタプル <name, domain, path> に基づいて一意に識別されると規定されています。しかし、EclipseVert.x の以前のリリースで使用されていた Map<String, Cookie> cookieMap() メソッドは、クッキーが名前のみに基づいて識別できると誤って想定していました。つまり、複数のクッキーが同じ名前を共有している場合、マップは解析される最後のクッキーを保持し、以前に解析された値はすべて警告なしで上書きされていました。

Eclipse Vert.x 4.2.0 は、GraphQL クエリー言語の Java サーバー実装である GraphQL Java のバージョン 17 をサポートします。GraphQL Java 17 では、GraphQLContext オブジェクトが GraphQL Java アプリケーションのコンポーネント間でコンテキストデータを共有するための標準になりました。

Eclipse Vert.x 4.2.0 では、GraphQL の実行を設定するために以下の新しいメカニズムが導入されました。

GraphQLHandler handler = GraphQLHandler.create(graphQL).beforeExecute(builderWithContext -> {
  DataLoader<String, Link> linkDataLoader = DataLoaderFactory.newDataLoader(linksBatchLoader);
  DataLoaderRegistry dataLoaderRegistry = new DataLoaderRegistry().register("link", linkDataLoader);
  builderWithContext.builder().dataLoaderRegistry(dataLoaderRegistry);
});

Eclipse Vert.x の以前のリリースでは、データローダーを設定するために Vert.x Web GraphQL ハンドラーで次のフックが使用されていました。以下のフックは Eclipse Vert.x 4.2.0 で非推奨になりました。

GraphQLHandler handler = GraphQLHandler.create(graphQL).dataLoaderRegistry(rc -> {
  DataLoader<String, Link> linkDataLoader = DataLoader.newDataLoader(linksBatchLoader);
  return new DataLoaderRegistry().register("link", linkDataLoader);
});

IBM Z および IBMPowerSystems の OpenJ9 イメージは非推奨になりました。次の OpenJDK11 イメージは、複数のアーキテクチャーをサポートするように更新されています。

OpenJDK11 イメージは、次のアーキテクチャーで使用できます。

Eclipse Vert.x の Red Hat ビルドは、FIPS 対応の RHEL システムで実行され、RHEL が提供する FIPS 認定ライブラリーを使用します。

Eclipse Vert.x 4.1.0 以降では、HTTP リダイレクトにヘッダーがある場合は、HTTP クライアントのリダイレクトハンドラーはヘッダーを次の要求に伝播します。この変更により、リダイレクトハンドラーは、リダイレクトされた要求全体をより詳細に制御できるようになります。

以前のリリースの Eclipse Vert.x では、ヘッダーのあるリダイレクト要求があったため、HTTP クライアントはリダイレクト後にヘッダーを処理していました。

以下の例は、Eclipse Vert.x 4.1.0 でリダイレクトを処理する方法を示しています。

RequestOptions options = new RequestOptions();
options.setMethod(HttpMethod.GET);
options.setHost(uri.getHost());
options.setPort(port);
options.setSsl(ssl);
options.setURI(requestURI);

// From 4.1.0 propagate headers
options.setHeaders(resp.request().headers());
options.removeHeader(CONTENT_LENGTH);

Eclipse Vert.x 4.1.0 では、Infinispan クラスターマネージャーが更新され、Infinispan 12 をベースにしています。

Infinispan 11 には、マルチマップキャッシュにバイトアレイを保存できないバグがありました。Eclipse Vert.x クラスターマネージャーは、内部 Infinispan クラス WrappedBytes を使用して eventbus サブスクリプションデータを保存する必要がありました。この問題は Infinispan 12 で修正されました。

Eclipse Vert.x 4.1.0 では、connection_string オプションが利用可能な場合でも JSON 設定オプションが適用されます。

次の設定オプションが適用されるようになりました。

{
    mongo:{
        db_name: "mydb"
        connection_string: "mongodb://localhost:27017"
        maxPoolSize: 10
        minPoolSize: 3
    }
}

以前のリリースの Eclipse Vert.x では、接続文字列が利用可能な場合に JSON 設定オプションは無視されていました。たとえば、前述の例を見てみましょう。以前のリリースの Eclipse Vert.x では、db_name、maxPoolSize、および minPoolSize オプションは無視されていました。

Eclipse Vert.x 4.0 以降では、スコープの処理に JWT および OAuth2 ハンドラーが使用されます。

Eclipse Vert.x 4.1.0 以降、JWTOptions.setScopes(List<String>)、JWTOptions.addScope(String)、および JWTOptions.withScopeDelimiter(String) メソッドが削除されました。これらのメソッドは仕様に準拠していませんでした。

以下の例は、Eclipse Vert.x 4.1.0 でスコープを処理する方法を示しています。

// before 4.1.0
JWTAuthOptions authConfig = new JWTAuthOptions()
  .setJWTOptions(new JWTOptions()
    .addScope("a")
    .addScope("b")
    .withScopeDelimiter(" ")));

JWTAuth authProvider = JWTAuth.create(vertx, authConfig);

router.route("/protected/*").handler(JWTAuthHandler.create(authProvider));

// in 4.1.0
JWTAuth authProvider = JWTAuth.create(vertx, new JWTAuthOptions());

router.route("/protected/*").handler(
  JWTAuthHandler.create(authProvider)
    .addScope("a")
    .addScope("b")
    .withScopeDelimiter(" "));

Eclipse Vert.x 4.1.0 から LoggerHandler.customFormatter(Function) メソッドが非推奨になりました。この関数は HttpServerRequest を入力として取り、フォーマットされたログ文字列を返します。出力は文字列であるため、コンテキストにアクセスすることはできません。

代わりに新しいメソッド LoggerHandler customFormatter(LoggerFormatter formatter) を使用してください。このメソッドは、コンテキストへのアクセスを提供するカスタムフォーマッターを入力として取ります。

Eclipse Vert.x 4.1.0 以降では、HTTP の失敗の処理に使用できる新しい例外クラス io.vertx.ext.web.handler.HttpException を利用できます。この例外を使用して、500 以外のカスタムステータスコードを指定できます。たとえば、新規の HttpException(401, "Forbidden") は、禁止されているリクエストがステータスコード 401 を返す必要があることを示します。

Eclipse Vert.x 4.1.0 以降では、RxJava 3 がサポートされます。

Eclipse Vert.x 4.0.3 以降、ContextServerInterceptor.bind () メソッドはすべてのタイプのデータをコンテキストにバインドします。このメソッドはストレージの詳細を公開しないため、より安全になりました。

Eclipse Vert.x 4.0.3 より前のリリースでは、このメソッドは 'String' データ型のみをコンテキストにバインドしていました。また、ストレージの詳細も公開しました。

更新された ContextServerInterceptor.bind () メソッドを使用するには、アプリケーションを更新する必要があります。

以下の例は、Eclipse Vert.x 4.0.3 より前のリリースのコードを示しています。

// Example code from previous releases

class X extends ContextServerInterceptor {
  @Override
  public void bind(Metadata metadata, ConcurrentMap<String, String> context) {

次の例は、Eclipse Vert.x 4.0.3 リリースの置換コードを示しています。

// Replacing code for Eclipse Vert.x 4.0.3 release

class X extends ContextServerInterceptor {
  @Override
  public void bind(Metadata metadata) {

Eclipse Vert.x 4.0.3 より前のリリースでは、ルートがスラッシュで終わるパスとワイルドカード /* で定義されている場合、一致するリクエストにも末尾のスラッシュ / が含まれている場合にのみ、ルートが呼び出されました。このルールは、ワイルドカードが空の場合に問題を引き起こしました。

Eclipse Vert.x 4.0.3 以降では、このルールは適用されなくなりました。パスがスラッシュ (/) で終わるルートを作成できます。ただし、リクエスト URL にスラッシュを指定することは必須ではありません。

また、リクエスト URL を作成および使用し、パスにスラッシュ (/) ではなく、ワイルドカードで終わるルートを呼び出すこともできます。たとえば、ワイルドカードが含まれるルートは /foo/* として定義できます。ここでは、ルートはパスの最後にあるオープンワイルドカードと一致する必要があります。リクエスト URL は /foo にすることができます。

この表は、Eclipse Vert.x 4.0.3 以前のリリースでのリクエスト URL /foo/ * を送信するときの動作を示しています。Eclipse Vert.x 4.0.3 では終了スラッシュが任意であり、要求はルートに一致することがわかります。

AutoRegistrationOfImporters 属性はサービス検出オプションから削除されました。

Eclipse Vert.x 4.0.3 より前のリリースでは、AuthenticationProvider.authenticate () メソッドが入力クレデンシャルとして jwt: someValue を誤って取得していました。

Eclipse Vert.x 4.0.3 以降、AuthenticationProvider.authenticate() メソッドが更新され、token: someValue が入力クレデンシャルとして取得されます。この変更により、JSON API と型指定された API の両方が一貫性を保ち、同じ意味で使用できるようになります。

以下のコードは、Eclipse Vert.x 4.0.3 より前のリリースでの認証メソッドの実装を示しています。

new JsonObject().put("jwt", "token...");

以下のコードは、Eclipse Vert.x 4.0.3 リリースの認証メソッドの実装を示しています。

new JsonObject().put("token", "token...");

PubSecKeyOptions.getBuffer() メソッドは、PEM またはシークレットキーバッファーを返します。Eclipse Vert.x 4.0.2 より前のリリースでは、キーバッファーが保存され String として返されました。ただし、シークレットを Buffer として保存することを推奨します。Eclipse Vert.x 4.0.2 以降では、メソッドはキーバッファーを保存し、Buffer として保存し返します。この変更により、シークレットのセキュリティーおよび処理が改善します。

PubSecKeyOptions.setBuffer() メソッドは String 引数を受け入れます。set メソッドでは、ASCII 以外のシークレット資料を安全に処理するために、バッファーのオーバーロードが追加されました。この変更には、既存のコードを変更する必要はありません。

Eclipse Vert.x 4 以降、KubernetesServiceImporter 検出ブリッジは自動的に登録されなくなりました。Maven プロジェクトのクラスパスにブリッジを追加しても、自動的に登録されません。

ServiceDiscovery インスタンスの作成後にブリッジを手動で登録する必要があります。

Eclipse Vert.x 4 は、非同期操作に future を使用します。すべての callback メソッドには、対応する future メソッドがあります。

future は非同期操作の作成に使用できます。future を使用する場合は、エラー処理の方が優れています。したがって、アプリケーションでコールバックと future の組み合わせを使用することが推奨されます。

Eclipse Vert.x 4 では、Jackson Databind は任意の Maven 依存関係です。この依存関係を使用する場合は、クラスパスに明示的に追加する必要があります。たとえば、オブジェクトマッピング JSON の場合は、依存関係を明示的に追加する必要があります。

Eclipse Vert.x 4 では、新機能が追加されています。以前の機能および機能は Eclipse Vert.x 4 で非推奨または削除されました。アプリケーションを Eclipse Vert.x 4 に移行する前に、非推奨および削除を確認します。

Java コンパイラーは、非推奨の API が使用されたときに警告を生成します。アプリケーションを Eclipse Vert.x 4 に移行する際に、コンパイラーを使用して非推奨のメソッドを確認できます。

Eclipse Vert.x 4 は分散トレースをサポートします。トレースを使用してマイクロサービスを監視し、パフォーマンスの問題を特定することができます。

Eclipse Vert.x 4 は OpenTracing システムと統合します。

以下の Eclipse Vert.x コンポーネントはトレースをログに記録できます。

Eclipse Vert.x 4 では、EventBus JavaScript クライアント vertx-web-client.js は Maven リポジトリーの Red Hat アーティファクトとして公開されません。

クライアントは npm リポジトリーに公開されます。@vertx/eventbus-bridge-client.js からクライアントにアクセスできます。

OpenShift Maven プラグインを使用して、OpenShift に Eclipse Vert.x アプリケーションをデプロイします。Fabric8 Maven プラグインはサポート対象外になりました。詳細は、migrating from Fabric8 Maven Plugin to Eclipse JKube セクションを参照してください。

メータリングラベルを Eclipse Vert.x Pod に追加し、OpenShift Metering Operator で Red Hat サブスクリプションの詳細を確認できます。

Eclipse Vert.x は、以下のメータリングラベルを使用する必要があります。

Eclipse Vert.x は、RHEL 8 上の Red Hat OpenJDK 8 および Red Hat OpenJDK 11 用の OCI 準拠の ユニバーサルベースイメージ を使用して、Eclipse Vert.x アプリケーションをビルドして OpenShift にデプロイするためのサポートを導入します。

RHEL 8 OpenJDK Universal Base イメージは、RHEL 8 OpenJDK ビルダーイメージを置き換えます。RHEL 8 OpenJDK ベースイメージは、Eclipse Vert.x との使用がサポートされなくなりました。