Eclipse Vert.x 4.3 リリースノート

Eclipse Vert.x 4.3.4 以降では、Micrometer 1.9.3 へのアップグレードにより、Java Management Extensions (JMX) で Eclipse Vert.x Micrometer Metrics を使用する場合、オブジェクト名にメトリックタイプが含まれるようになりました。

この拡張機能は、micrometer-registry-jmx モジュールのユーザーにのみ関連します。

Eclipse Vert.x 4.3.3 以降、Eclipse Vert.x は GraphQL Java のバージョン 19 をサポートします。これは、GraphQL クエリー言語の Java サーバー実装です。GraphQL Java 19 を使用する場合、JVM でロケールを設定しない場合、GraphQL エンジンは、JVM がインストールされているプラットフォームのロケールである JVM デフォルトロケールを使用するようになりました。あるいは、別の値を使用するように JVM デフォルト Locale を設定するか、Eclipse Vert.x Web GraphQL ハンドラーを使用してカスタムロケールを設定することができます。

Eclipse Vert.x 4.3.2 以降では、Jackson Databind ライブラリーを vertx-web-openapi、vertx-auth-webauthn、または vertx-config-yaml モジュールで使用する場合、次の依存関係をプロジェクト記述子に追加する必要があります。

<dependency>
  <groupId>com.fasterxml.jackson.core</groupId>
  <artifactId>jackson-databind</artifactId>
</dependency>

Jackson Databind ライブラリーはいくつかのセキュリティー上の脆弱性を引き起こし、他のモジュールは通常、何らかの内部動作を行うためにのみ Jackson Databind を使用するため、Eclipse Vert.x パーサーの使用は、Jackson Databind とともに vertx-web-openapi、vertx-auth-webauthn、または vertx-config-yaml モジュールを使用する必要よりも優先されます。ただし、Jackson Databind でこれらのモジュールのいずれかを引き続き使用する場合は、前の例に示すように、プロジェクトにこの依存関係を明示的に含める必要があります。

Eclipse Vert.x 4.3.1 以降、Eclipse Vert.x OpenAPI では routerBuilder.rootHandler() メソッドを使用して、PLATFORM または SECURITY_POLICY ハンドラーの 後 にボディハンドラーが正しい順序で設定されるようにする必要があります。

以下に例を示します。

BodyHandler bodyHandler = BodyHandler.create("my-uploads");
routerBuilder.rootHandler(bodyHandler);

Eclipse Vert.x の以前のリリースでは、Eclipse Vert.x OpenAPI は、本体ハンドラーを追加するための routerBuild.bodyHandler() メソッドをサポートしていました。ただし、bodyHandler() メソッドには次の欠点がありました。

bodyHandler() メソッドは、Eclipse Vert.x 4.3.1 で非推奨になりました。以前の rootHandler 呼び出しは、以前のバージョンで使用可能だった次の bodyHandler 呼び出しに取って代わります。

BodyHandler bodyHandler = BodyHandler.create("my-uploads");
routerBuilder.bodyHandler(bodyHandler);

Eclipse Vert.x 4.3.1 以降、Eclipse Vert.x リアクティブ Oracle クライアントには、BLOB および RAW データに対する次の機能強化が含まれています。

Eclipse Vert.x 4.3.1 以降、Eclipse Vert.x Oracle リアクティブクライアントでは、自動生成されたキーの取得はデフォルトで無効になっています。ほとんどのアプリケーションは ROWID に依存しないため、Eclipse Vert.x Oracle リアクティブクライアントは通常、自動生成されたキーを取得する必要はありません。

この機能強化により、自動生成されたキーの取得が有効になっていると正常に実行できない INSERT…SELECT などのクエリーも容易になります。

Eclipse Vert.x 4.3.0 以降、Eclipse Vert.x は io.vertx.core.shareddata.ClusterSerializable インターフェイスをサポートし、これらのオブジェクトが AsyncMap から読み取られるか、またはバッファーからデコードされるときに、バッファーとの間でオブジェクトを読み書きします。EventBus メッセージ本文。

Eclipse Vert.x の以前のリリースでは、io.vertx.core.shareddata.impl.ClusterSerializable インターフェイスがサポートされていました。ただし、このインターフェイスは実装パッケージで提供されていたため、信頼性が低い可能性があると考えられていました。io.vertx.core.shareddata.impl.ClusterSerializable インターフェイスは、Eclipse Vert.x 4.3.0 で廃止され、公開されました。

Eclipse Vert.x 4.3.0 以降、MicrometerMetricsOptions クラスで、サーバー要求メトリックの requestsTagsProvider オプションの名前が serverRequestTagsProvider に変更されました。同様の clientRequestTagsProvider オプションがクライアント要求メトリックにも使用できるようになったため、この拡張が必要です。

Eclipse Vert.x の以前のリリースでは、requestsTagsProvider オプションは、それぞれ getRequestsTagsProvider と setRequestsTagsProvider という名前の getter と setter を使用していました。Eclipse Vert.x 4.3.0 以降のバージョンでは、serverRequestTagsProvider オプションのゲッターとセッターの名前が getServerRequestTagsProvider と setServerRequestTagsProvider に変更されました。

Eclipse Vert.x 4.3.0 以降では、OAuth2 認証が on-behalf-of (OBO) モードで設定されている場合、OAuth2 では、リクエストを認証するために OAuth2Credentials オブジェクトを明示的に指定する必要があります。

以下に例を示します。

oauth2.authenticate(
  new Oauth2Credentials().setAssertion("head.body.signature").addScope("a").addScope("b"))

Eclipse Vert.x の以前のリリースでは、OBO モードの OAuth2 認証で TokenCredentials を使用できました。ただし、このフローはオプションであるため、同じ OAuth2Credentials オブジェクトを再利用できるようにするために、以前のバージョンで使用できた次のタイプの TokenCredentials 呼び出しが、前述の Oauth2Credentials 呼び出しに取って代わります。

oauth2.authenticate(
  new TokenCredentials("head.body.signature").addScope("a").addScope("b"));

Eclipse Vert.x 4.3.0 以降では、RoutingContext.fileUploads() メソッドは List<FileUpload> 値を返します。ファイルのアップロードをリストに保存すると、アップロードの順序を維持するのに役立ちます。

以下に例を示します。

List<FileUpload> uploads = ctx.fileUploads();

Eclipse Vert.x の以前のリリースでは、RoutingContext.fileUploads() メソッドは Set<FileUpload> 値を返しました。ただし、ファイルアップロードをセットに格納することは、フォームコンテンツタイプの World Wide Web Consortium (W3C) 仕様と一致しませんでした。これは、正しい順序が保持されず、ユーザーがアップロード名を一意のキーとして信頼できないためです。前の例は、以前のバージョンで使用できた次のメソッド宣言に取って代わります。

Set<FileUpload> uploads = ctx.fileUploads();

Eclipse Vert.x 4.3.0 以降では、Route.subRouter(Router) メソッドが、サブルーターを実装するためにサポートされている唯一の方法です。

Eclipse Vert.x の以前のリリースでは、サブルーターを実装するための 2 つの異なる方法がサポートされていました。

ただし、Router.mountSubRouter メソッドは任意のパスを許可するのに対し、Route.subRouter メソッドはサブルーティングパスを表すためにワイルドカードアスタリスク (*) を明示的に要求するため、これら 2 つのメソッド間の動作には一貫性がありませんでした。Router.mountSubRouter メソッドも、欠落しているワイルドカードを追加することで Route.subRouter メソッドに委任されました。

Eclipse Vert.x 4.3.0 以降のバージョンでは、Router.mountSubRouter メソッドは非推奨です。Router オブジェクトは、サブルーターを実装するために Route.subRouter メソッドも使用する必要があります。以下に例を示します。

router.route("/eventbus/*").subRouter(otherRouter);

以前の router.route().subRouter() 呼び出しは、以前のバージョンで使用可能だった次のタイプの router.mountSubRouter() 呼び出しに取って代わります。

router.mountSubRouter("/eventbus", otherRouter);

Eclipse Vert.x 4.3.0 以降では、ボディハンドラーが Web リクエストのボディを解析した後、ボディハンドラーはボディバッファーをリクエストのルーティングコンテキストに提供します。 ルーティングコンテキストでボディバッファーをキャッシュすることは、要求ボディのデコードされたビューを必要とする複数の異なるハンドラーが、ボディを再度解析することなく、キャッシュされた結果を取得できることを意味します。 この拡張機能は、本文のコンテンツがタイプ application/json である状況もサポートします。

RoutingContext クラスは、要求本文を指定されたタイプとして取得するために使用される新しい body() メソッドを提供します。

以下に例を示します。

RoutingContext.body().asString()
RoutingContext.body().asString(String encoding)
RoutingContext.body().asJsonObject()
RoutingContext.body().asJsonArray()
RoutingContext.body().asJsonObject(int maxLength)
RoutingContext.body().asJsonArray(int maxLength)
RoutingContext.body().buffer()

新しい body() ゲッターは、次の追加機能も提供します。

// the length of the buffer (-1) for null buffers
RoutingContext.body().length()

// Converting to POJO
RoutingContext.body().asPOJO(Class<T> clazz)
RoutingContext.body().asPOJO(Class<T> clazz, int maxLength)

この拡張機能には、次の利点があります。

Eclipse Vert.x の以前のリリースでは、RoutingContext クラスは次のメソッドを提供していましたが、現在は body() メソッドを使用するために推奨されていません。

RoutingContext.getBodyAsString()
RoutingContext.getBodyAsString(String encoding)
RoutingContext.getBodyAsJson()
RoutingContext.getBodyAsJsonArray()
RoutingContext.getBodyAsJson(int maxLength)
RoutingContext.getBodyAsJsonArray(int maxLength)
RoutingContext.getBody()

Eclipse Vert.x 4.3.0 以降では、不必要なトラフィックを回避するために、Eclipse Vert.x サーキットブレーカーの状態の変化に関する通知がデフォルトで無効になっています。これらの通知を有効にするには、null 以外のパラメーターを指定して CircuitBreakerOptions オブジェクトの setNotificationAddress メソッドを呼び出します。

以下に例を示します。

CircuitBreakerOptions options = new CircuitBreakerOptions()
    .setNotificationAddress(CircuitBreakerOptions.DEFAULT_NOTIFICATION_ADDRESS);

前の例に示すように通知を有効にすると、既定の動作では、ローカルコンシューマーにのみ通知が送信されます。クラスター全体で通知を送信するには、false のパラメーターを指定して setNotificationLocalOnly メソッドを呼び出します。

以下に例を示します。

CircuitBreakerOptions options = new CircuitBreakerOptions()
    .setNotificationAddress(CircuitBreakerOptions.DEFAULT_NOTIFICATION_ADDRESS)
    .setNotificationLocalOnly(false);

Eclipse Vert.x 4.3.0 以降、Eclipse Vert.x リアクティブ SQL クライアントはパイプラインクエリーをサポートし、デフォルトでパイプラインモードでバッチクエリーを実行します。パイプライン処理とは、前の要求への応答を待たずに、同じ接続で要求が送信されることを意味します。

Eclipse Vert.x の以前のリリースでは、MySQL にはバッチ処理のネイティブプロトコルサポートがないため、SQL クライアントは準備されたクエリーを順番に実行することでバッチクエリーを実行し、ユーザーは API 呼び出しを介して直接操作できました。

Eclipse Vert.x 4.3.0 以降、Eclipse Vert.x には、ヒントとヒント文字列に関する次の MongoDB 拡張機能が含まれています。

Eclipse Vert.x 4.3.0 以降では、スキーマを構築するときに、Eclipse Vert.x JSON スキーマが提供する JSON 表現を使用します。JSON 表現では、任意のバリデーターを使用できます。

以下に例を示します。

JsonSchema schema = JsonSchema.of(dsl.toJson());

Eclipse Vert.x の以前のリリースでは、SchemaBuilder クラスが build() メソッドを提供していましたが、これにはバリデーターの特定の実装を使用する必要がありました。build() メソッドは、Eclipse Vert.x 4.3.0 で非推奨になりました。前述の JsonSchema の例は、以前のバージョンで使用できた次のタイプの build() メソッド呼び出しに取って代わります。

Schema schema = dsl.build(parser);

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 との使用がサポートされなくなりました。