WriteStream<T>.write（） メソッドおよび WriteStream<T>.end（） メソッドは fluent ではなくなりました。

これは重大な変更です。書き込みストリームに fluent 側面を使用している場合は、アプリケーションを更新します。

MessageProducer インターフェースは WriteStream インターフェースを拡張しません。

以前のリリースの Eclipse Vert.x では、MessageProducer インターフェースは WriteStream インターフェースを拡張しました。MessageProducer インターフェースは、メッセージのバックプレッシャーに対する制限されたサポートを提供していました。クレジットリークにより、メッセージプロデューサーのクレジットが減ります。これらのリークがすべてクレジットを使用する場合、メッセージは送信されません。

ただし、MessageConsumer は、ReadStream の拡張機能 を継続します。MessageConsumer が一時停止し、保留中のメッセージキューが満杯になると、メッセージは破棄されます。これにより、Rx ジェネレーターとのインテグレーションが継続され、消費するパイプラインのメッセージが作成されます。

MessageProducer インターフェースの送信メソッドが削除されました。

MessageProducer<T>.send(T)の代わりに MessageProducer<T>.write (T)メソッドを使用し、MessageProducer .send ( T,Handler)の代わりに EventBus.request(String,Object,Handler) メソッドを使用してください。

EventBus.send(…​, Handler<AsyncResult<Message<T>>>) メソッドおよび Message.reply(…​, Handler<AsyncResult<Message<T>>>) メソッドが削除されました。これらのメソッドにより、Eclipse Vert.x 4 でオーバーロードの問題が生じました。Future<Message<T>> メソッドのバージョンは、fire および forget バージョンと競合します。

Request-response メッセージングパターンでは、新しい request メソッドおよび replyAndRequest メソッドを使用する必要があります。

以下の例は、Eclipse Vert.x 3.x リリースのメッセージに対する要求および応答を示しています。

eventBus.send("the-address", body, ar -> ...);

eventBus.consumer("the-address", message -> {
       message.reply(body, ar -> ...);
});

以下の例は、Eclipse Vert.x 4 のメッセージへの要求および応答を示しています。

eventBus.request("the-address", body, ar -> ...);

eventBus.consumer("the-address", message -> {
  message.replyAndRequest(body, ar -> ...);
});

Eclipse Vert.x 4 以降では、今後、複数のハンドラーがサポートされます。単一のハンドラーを設定するために使用される Future<T>.setHandler（） メソッドは削除されました。代わりに、Future<T>.onComplete（） メソッド、Future<T>.onSuccess（） メソッド、および Future<T>.onFailure（） メソッドを使用して、動作の完了、成功、および失敗の結果でハンドラーを呼び出します。

以下の例は、Eclipse Vert.x 3.x リリースでハンドラーを呼び出す方法を示しています。

Future<String> fut = getSomeFuture();
fut.setHandler(ar -> ...);

以下の例は、Eclipse Vert.x 4 で新しい Future<T>.onComplete（） メソッドを呼び出す方法を示しています。

Future<String> fut = getSomeFuture();
fut.onComplete(ar -> ...);

以前のリリースの Eclipse Vert.x では、Future.completer（） メソッドを使用して、Future と関連付けられた Handler<AsyncResult<T>> にアクセスします。

Eclipse Vert.x 4 では、Future<T>.completer（） メソッドが削除されました。Future<T> は Handler<AsyncResult<T>> を直接拡張します。Future オブジェクトを使用してすべてのハンドラーメソッドにアクセスできます。Future オブジェクトはハンドラーでもあります。

HttpClientRequest.connectionHandler（） メソッドが削除されました。代わりに HttpClient.connectionHandler（） メソッドを使用して、アプリケーションのクライアントリクエストの接続ハンドラーを呼び出します。

以下の例は、HttpClientRequest.connectionHandler（） メソッドが Eclipse Vert.x 3.x リリースでどのように使用されたかを示しています。

client.request().connectionHandler(conn -> {
  // Connection related code
}).end();

以下の例は、Eclipse Vert.x 4 で新しい HttpClient.connectionHandler（） メソッドを使用する方法を示しています。

client.connectionHandler(conn -> {
  // Connection related code
});

以前のリリースの Eclipse Vert.x では、VerticleFactory.createVerticle（） メソッドが verticle を同期的にインスタンス化しました。Eclipse Vert.x 4 以降では、メソッドは非同期的に verticle をインスタンス化し、単一の verticle インスタンスではなく、コールバック Callable<Verticle> を返します。この改善により、アプリケーションはこのメソッドを一度呼び出し、複数のインスタンスを作成するために、返された呼び出し可能な複数回呼び出すことができます。

以下のコードは、Eclipse Vert.x 3.x リリースで verticle がインスタンス化される方法を示しています。

Verticle createVerticle(String verticleName, ClassLoader classLoader) throws Exception;

以下のコードは、Eclipse Vert.x 4 で verticle がインスタンス化される方法を示しています。

void createVerticle(String verticleName, ClassLoader classLoader, Promise<Callable<Verticle>> promise);

VerticleFactory クラスが簡素化されました。ファクトリーはネストされたデプロイメントを使用して verticle をデプロイすることができるため、クラスは識別子の初期解決を必要としません。

既存のアプリケーションが factory を使用する場合、Eclipse Vert.x 4 では、promise の完了または失敗時に callable を使用するようにコードを更新できます。呼び出し可能なものは複数回呼び出すことができます。

以下の例は、Eclipse Vert.x 3.x アプリケーションの既存のファクトリーを示しています。

return new MyVerticle();

以下の例は、Eclipse Vert.x 4 で promise を使用するように既存のファクトリーを更新する方法を示しています。

promise.complete(() -> new MyVerticle());

Factory がコードをブロックするようにするには、Vertx .executeBlocking（） メソッドを使用します。ファクトリーがブロックコードを受け取ると、promise を解決し、promise から verticle インスタンスを取得する必要があります。

マルチスレッドのワーカー verticle デプロイメントオプションが削除されました。この機能は、Eclipse Vert.x event-bus とのみ使用できます。HTTP などの他の Eclipse Vert.x コンポーネントはこの機能をサポートしません。

順序のない Vertx.executeBlocking（） メソッドを使用して、マルチスレッドワーカーのデプロイメントと同じ機能を実現します。

Vertx.getOrCreateContext（） メソッドは、非 Eclipse Vert.x スレッドごとに単一のコンテキストを作成します。非 Eclipse Vert.x スレッドは、コンテキストの初回作成時にコンテキストに関連付けられます。以前のリリースでは、Eclipse Vert.x 以外のスレッドからメソッドが呼び出されるたびに、新しいコンテキストが作成されていました。

new Thread(() -> {
  assertSame(vertx.getOrCreateContext(), vertx.getOrCreateContext());
}).start();

アプリケーションが呼び出しごとに作成される新しいコンテキストに暗黙的に依存しない限り、この変更はアプリケーションに影響を与えません。

以下の例では、各ブロックコードが異なるコンテキストで呼び出されるため、n ブロックが同時に実行されます。

for (int i = 0;i < n;i++) {
  vertx.executeBlocking(block, handler);
}

Eclipse Vert.x 4 で同じ結果を取得するには、コードを更新する必要があります。

for (int i = 0;i < n;i++) {
  vertx.executeBlocking(block, false, handler);
}

以下のセクションでは、Eclipse Vert.x HTTP メソッドにおけるその他の更新を説明します。

// 3.x
options.setMaxPoolSize(30); // Maximum connection is set to 30 for each endpoint

// 4.x
options.setMaxWebSockets(30); // Maximum connection is set to 30 for each endpoint

switch (method) {
  case GET:
    ...
    break;
  case OTHER:
    String s = request.getRawMethod();
    if (s.equals("PROPFIND") {
      ...
    } else ...
}

switch (method.name()) {
  case "GET":
    ...
    break;
  case "PROPFIND";
    ...
    break;
}

HttpMethod PROPFIND = HttpMethod.valueOf("PROPFIND");

if (method == HttpMethod.GET) {
  ...
} else if (method.equals(PROPFIND)) {
  ...
} else {
  ...
}

client.request(HttpMethod.OTHER, ...).setRawName("PROPFIND");

client.request(HttpMethod.valueOf("PROPFIND"), ...);

本セクションでは、HTTP クライアントの変更点を説明します。

以下のタイプの Eclipse Vert.x クライアントを利用できます。

HttpClientRequest request = client.get(80, "example.com", "/", response -> {
  int statusCode = response.statusCode();
  response.exceptionHandler(err -> {
    // Handle connection error, for example, connection closed
  });
  response.bodyHandler(body -> {
    // Handle body entirely
  });
});
request.exceptionHandler(err -> {
  // Handle connection error OR response error
});
request.end();

client.get(80, "example.com", "/some-uri")
  .send(ar -> {
    if (ar.suceeded()) {
      HttpResponse<Buffer> response = ar.result();
      // Handle response
    }  else {
      // Handle error
    }
  });

HttpClientRequest request = client.get(80, "example.com", "/", response -> {
  int statusCode = response.statusCode();
  response.exceptionHandler(err -> {
    // Handle connection error, for example, connection closed
  });
  response.bodyHandler(body -> {
    // Handle body entirely
  });
});
request.exceptionHandler(err -> {
  // Handle connection error OR response error
});
request.end();

client.request(HttpMethod.GET, 80, "example.com", "/", ar -> {
  if (ar.succeeded()) {
    HttpClientRequest = ar.result();
    request.send(ar2 -> {
      if (ar2.succeeded()) {
        HttpClientResponse = ar2.result();
        int statusCode = response.statusCode();
        response.body(ar3 -> {
          if (ar3.succeeded()) {
            Buffer body = ar3.result();
            // Handle body entirely
          } else {
            // Handle server error, for example, connection closed
          }
        });
      } else {
        // Handle server error, for example, connection closed
      }
    });
  } else {
    // Connection error, for example, invalid server or invalid SSL certificate
  }
});

Future<Buffer> fut = client.request(HttpMethod.GET, 80, "example.com", "/")
  .compose(request -> request.send().compose(response -> {
    int statusCode = response.statusCode();
    if (statusCode == 200) {
      return response.body();
    } else {
      return Future.failedFuture("Unexpectd status code");
    }
  })
});
fut.onComplete(ar -> {
  if (ar.succeeded()) {
    Buffer body = ar.result();
    // Handle body entirely
  } else {
    // Handle error
  }
});

request.end();

request.end(Buffer.buffer("hello world));

writeStream.pipeTo(request, ar -> {
  if (ar.succeeded()) {
    // Sent the stream
  }
});

// Send a request and process the response
request.onComplete(ar -> {
  if (ar.succeeded()) {
    HttpClientResponse response = ar.result();
    // Handle the response
  }
})
request.end();

// The new send method combines all the operations
request.send(ar -> {
  if (ar.succeeded()) {
    HttpClientResponse response = ar.result();
    // Handle the response
  }
}));

HttpClient client = vertx.createHttpClient(options);

    client.request(HttpMethod.GET, 8443, "localhost", "/")
      .onSuccess(request -> {
        request.onSuccess(resp -> {

        //Code to handle HTTP response
        });
      });

HttpClient client = vertx.createHttpClient(options);

    client.request(HttpMethod.GET, 8443, "localhost", "/")
      .onSuccess(request -> {
        request.response().onSuccess(resp -> {

        //Code to handle HTTP response
        });
      });

client.request(HttpMethod.GET, 8080, "example.com", "/resource", ar -> {
  if (ar.succeeded()) {
    HttpClientRequest request = ar.result();
    request.putHeader("content-type", "application/json")
    request.send(new JsonObject().put("hello", "world"))
      .onSuccess(response -> {
      //
      }).onFailure(err -> {
      //
       });
     }
})

client.request().connectionHandler(conn -> {
  // Connection related code
}).end();

client.connectionHandler(conn -> {
// Connection related code
});

client.request(HttpMethod.CONNECT, uri, ar -> {
  if (ar.succeeded()) {
    HttpClientResponse response = ar.result();
    if (response.statusCode() == 200) {
      NetSocket so = response.netSocket();
   }
  }
}).end();

client.request(HttpMethod.CONNECT, uri, ar -> {
}).netSocket(ar -> {
  if (ar.succeeded()) {
   // Got a response with a 200 status code
   NetSocket so = ar.result();
   // Go for tunneling
  }
}).end();

Future<HttpClientResponse> f1 = client.send(HttpMethod.GET, 8080, "localhost", "/uri", HttpHeaders.set("foo", "bar"));

MultiMap headers = MultiMap.caseInsensitiveMultiMap();

MultiMap headers = HttpHeaders.headers();

MultiMap headers = HttpHeaders.set("content-type", "application.data");

CaseInsensitiveHeaders headers = new CaseInsensitiveHeaders();

MultiMap multiMap = MultiMap#caseInsensitiveMultiMap();

MultiMap headers = HttpHeaders.headers();

client.request(HttpMethod.GET, 8080, "example.com", "/resource", ar -> {
  if (ar.succeeded()) {
    HttpClientRequest request = ar.result();
    request.putHeader("content-type", "application/json")
    request.send(new JsonObject().put("hello", "world"))
      .onSuccess(response -> {
      //
      }).onFailure(err -> {
      //
       });
     }
})

NetServerOptions.isClientAuthRequired（） メソッドが削除されました。Get ClientAuth（）== ClientAuth.REQUIRED 列挙タイプを使用して、クライアント認証が必要であるかどうかを確認します。

以下の例は、switch ステートメントを使用して、クライアントの認証が必要であるかどうかを確認する方法を示しています。

switch (options.getClientAuth()) {
case REQUIRED:
// ... behavior same as in releases prior to {VertX} {v4}
break;
default:
// fallback statement...
}

以下の例は、Eclipse Vert.x 4 でクライアントの認証が必要な場合にチェックを使用する方法を示しています。

if (options.getClientAuth() == ClientAuth.REQUIRED) {
// behavior in releases prior to {VertX} {v4}

The NetSocket.upgradeToSsl（） メソッドが更新され、Handler ではなく Handler <AsyncResult> が使用されるようになりました。ハンドラーは、チャネルが SSL または TLS に正常にアップグレードされているかどうかを確認するために使用されます。

ロギングクラス Logger および LoggerFactory と、それらのメソッドが非推奨になりました。これらのロギングクラスおよびメソッドは今後のリリースで削除されます。

Log4j 1 ロガーは利用できなくなりました。ただし、Log4j 1 ロガーを使用する場合は SLF4J で利用できます。

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

RxJava 3 にアップグレードするには、以下の変更を加える必要があります。

WriteStreamSubscriber.onComplete（） コールバックが削除されました。このコールバックは、WriteStream が書き込まれるデータのストリームが保留中の場合に呼び出されました。

Eclipse Vert.x 4 では、代わりに WriteStreamSubscriber.onWriteStreamEnd（） コールバックおよび WriteStreamSubscriber.onWriteStreamError（） コールバックを使用します。これらのコールバックは、WriteStream.end（） の完了後に呼び出されます。

WriteStreamSubscriber<Buffer> subscriber = writeStream.toSubscriber();

以下の例は、Eclipse Vert.x 3.x リリースの WriteStream からアダプターを作成する方法を示しています。

subscriber.onComplete(() -> {
    // Called after writeStream.end() is invoked, even if operation has not completed
});

以下の例は、Eclipse Vert.x 4 リリースの新しいコールバックメソッドを使用して WriteStream からアダプターを作成する方法を示しています。

subscriber.onWriteStreamEnd(() -> {
    // Called after writeStream.end() is invoked and completes successfully
});

subscriber.onWriteStreamError(() -> {
    // Called after writeStream.end() is invoked and fails
});

ConfigRetriever.getConfigAsFuture（） メソッドが削除されました。代わりに retriever.getConfig（） メソッドを使用してください。

以下の例は、Eclipse Vert.x 3.x リリースで設定を取得する方法を示しています。

Future<JsonObject> fut = ConfigRetriever. getConfigAsFuture(retriever);

以下の例は、Eclipse Vert.x 4 で設定を取得する方法を示しています。

fut = retriever.getConfig();

Jackson 型を実装する JSON クラスのメソッドがすべて削除されました。代わりに以下の方法を使用してください。

たとえば、以下のコードを使用します。

以前のリリースでは、Jackson コアおよび Jackson databind の依存関係はランタイム時に必要でした。

Eclipse Vert.x 4 以降では、Jackson コア依存関係のみが必要になります。

オブジェクトマッピング JSON の場合のみ、Jackson databind の依存関係が必要です。この場合、com.fasterxml.jackson.core:jackson-databind jar でプロジェクト記述子に依存関係を明示的に追加する必要があります。

以下のメソッドは上記の型でサポートされます。

以下のメソッドは、Jackson バインドでのみサポートされます。

Eclipse Vert.x JSON タイプは RFC-7493 を実装します。以前のリリースの Eclipse Vert.x では、実装は Base64URL ではなく Base64 エンコーダーが誤って使用されていました。これは Eclipse Vert.x 4 で修正され、JSON タイプで Base64URL エンコーダーが使用されるようになりました。

Eclipse Vert.x 4 で Base64 エンコーダーを引き続き使用する場合は、設定フラグの legacy を使用できます。以下の例は、Eclipse Vert.x 4 で設定フラグを設定する方法を示しています。

java -Dvertx.json.base64=legacy ...

アプリケーションを部分的に移行している場合は、Eclipse Vert.x 3.x から Eclipse Vert.x 4 への移行中に、バージョン 3 と 4 の両方にアプリケーションが必要になります。Eclipse Vert.x のバージョンが 2 つある場合は、次のユーティリティーを使用して Base64 文字列を Base64URL に変換できます。

public String toBase64(String base64Url) {
  return base64Url
    .replace('+', '-')
    .replace('/', '_');
}

public String toBase64Url(String base64) {
  return base64
    .replace('-', '+')
    .replace('_', '/');
}

以下のシナリオでは、ユーティリティーメソッドを使用する必要があります。

以下のコード例を使用して、Base64URL を Base64 エンコーダーに変換します。

String base64url = someJsonObject.getString("base64encodedElement")
String base64 = toBase64(base64url);

To Base64 および toBase64 Url のヘルパー関数は、JSON の移行だけを有効にします。オブジェクトマッピングを使用して JSON オブジェクトをアプリケーションの Java POJO に自動的にマッピングする場合、Base64 文字列を Base64URL に変換するためにカスタムオブジェクトマッパーを作成する必要があります。

以下の例は、カスタム Base64 デコーダーでオブジェクトマッパーを作成する方法を示しています。

// simple deserializer from Base64 to byte[]
class ByteArrayDeserializer extends JsonDeserializer<byte[]> {
  ByteArrayDeserializer() {
  }

  public byte[] deserialize(JsonParser p, DeserializationContext ctxt) {
    String text = p.getText();
    return Base64.getDecoder()
      .decode(text);
  }
}

// ...

ObjectMapper mapper = new ObjectMapper();

// create a custom module to address the Base64 decoding
SimpleModule module = new SimpleModule();
module.addDeserializer(byte[].class, new ByteArrayDeserializer());
mapper.registerModule(module);

// JSON to POJO with custom deserializer
mapper.readValue(json, MyClass.class);

TrustOptions.toJSON メソッドが削除されました。

以前のリリースの Eclipse Vert.x では、セッションで作業する際に UserSessionHandler ハンドラーと SessionHandler ハンドラーの両方を指定する必要がありました。

プロセスを単純化するために、Eclipse Vert.x 4 では UserSessionHandler クラスが削除され、その機能が SessionHandler クラスに追加されました。Eclipse Vert.x 4 では、セッションを使用するには 1 つのハンドラーのみを指定する必要があります。

以下の Cookie インターフェースが削除されました。

代わりに io.vertx.core.http.Cookie インターフェースを使用してください。

FaviconHandler および ErrorHandler で create メソッドが更新されました。Create メソッドで Vertx インスタンスオブジェクトを渡す必要があります。これらのメソッドはファイルシステムにアクセスします。Vertx オブジェクトを渡すと、'Vertx' ファイルシステムを使用するファイルへのアクセスの一貫性が確保されます。

以下の例は、Eclipse Vert.x 3.x リリースで create メソッドを使用する方法を示しています。

FaviconHandler.create();
ErrorHandler.create();

以下の例は、Eclipse Vert.x 4 で create メソッドを使用する方法を示しています。

FaviconHandler.create(vertx);
ErrorHandler.create(vertx);

Method TemplateEngine.unwrap（） を使用してテンプレートエンジンにアクセスします。その後、カスタマイズおよび設定をテンプレートに適用できます。

エンジン設定の取得および設定に使用される以下のメソッドは非推奨になりました。代わりに the TemplateEngine.unwrap（） メソッドを使用します。

Io .vertx.ext.web.Locale インターフェースが削除されました。代わりに io.vertx.ext.web.LanguageHeader インターフェースを使用してください。

RoutingContext.acceptableLocales（） メソッドが削除されました。代わりに RoutingContext.acceptableLanguages（） メソッドを使用してください。

以前のリリースの Eclipse Vert.x では、Router .mountSubRouter（） メソッドが Router を誤って返していました。これは修正され、メソッドが Route を返すようになりました。

JWTAuthHandler.create(JWTAuth authProvider, String skip) メソッドが削除されました。代わりに JWTAuthHandler.create(JWTAuth authProvider) メソッドを使用します。

以下の例は、Eclipse Vert.x 3.x リリースで JWT 認証ハンドラーが作成された方法を表しています。

router
   // protect everything but "/excluded/path"
   .route().handler(JWTAuthHandler(jwtAuth, "/excluded/path")

以下の例は、Eclipse Vert.x 4 で JWT 認証ハンドラーが作成された方法を表しています。

router
   .route("/excluded/path").handler(/* public access to "/excluded/path" */)
   // protect everything
   .route().handler(JWTAuthHandler(jwtAuth)

Eclipse Vert.x 4 では、OSGi 環境はサポートされなくなりました。StaticHandler.create(String, ClassLoader) メソッドは OSGi 環境で使用されたため、削除されました。

アプリケーションでこの方法を使用した場合は、Eclipse Vert.x 4 でリソースをアプリケーションクラスパスに追加するか、ファイルシステムからリソースを提供できます。

Sockjs.BridgeOptions クラスが削除されました。代わりに新しい sockjs.SockJSBridgeOptions クラスを使用してください。Sockjs.SockJSBridgeOptions クラスには、イベントバスブリッジの設定に必要なすべてのオプションが含まれます。

データオブジェクトクラスの名前が変更された場合を除き、新しいクラスの動作は変更されません。

以前のリリースでは、sock js.BridgeOptions クラスを使用して新規ブリッジを追加すると、多くの重複した設定がありました。新しいクラスには可能な共通設定がすべて含まれ、重複した設定を削除します。

SockJSSocket は、デフォルトでクラスター化されたイベントバスコンシューマーを登録しなくなりました。イベントバスを使用してソケットに書き込む場合は、Sonck JSHandlerOptions で writeHandler を有効にする必要があります。WriteHandler を有効にすると、イベントバスコンシューマーはデフォルトでローカルに設定されます。

Router router = Router.router(vertx);
SockJSHandlerOptions options = new SockJSHandlerOptions()
  .setRegisterWriteHandler(true); // enable the event bus consumer registration
SockJSHandler sockJSHandler = SockJSHandler.create(vertx, options);
router.mountSubRouter("/myapp", sockJSHandler.socketHandler(sockJSSocket -> {
  // Retrieve the writeHandlerID and store it (For example, in a local map)
  String writeHandlerID = sockJSSocket.writeHandlerID();
}));

イベントバスコンシューマーをクラスターに設定できます。

SockJSHandlerOptions options = new SockJSHandlerOptions()
  .setRegisterWriteHandler(true) // enable the event bus consumer registration
  .setLocalWriteHandler(false) // register a clustered event bus consumer

SessionHandler.setAuthProvider(AuthProvider) メソッドが非推奨になりました。代わりに SessionHandler.addAuthProvider（） メソッドを使用してください。新しいメソッドにより、アプリケーションは複数の認証プロバイダーと連携でき、セッションオブジェクトをこれらの認証プロバイダーにリンクできます。

Eclipse Vert.x 4 以降、OAuth2Auth.create(Vertx vertx) メソッドには、コンストラクター引数として vertx が必要です。Vertx 引数は、安全な非ブロッキングの乱数ジェネレーターを使用して nonce を生成するため、アプリケーションのセキュリティーが向上します。

以下のメソッドが更新され、polyglot 環境でサポートされるようになりました。* UploadScalar がファクトリーとなりました。代わりに UploadScalar.create（） メソッドを使用してください。

本リリース以前は、Eclipse Vert.x Web GraphQL ハンドラーが独自の POST 要求を処理する可能性がありました。要求を処理するのに Eclipse Vert.x Web BodyHandler は必要ありませんでした。ただし、この実装は DDoS 攻撃の影響を受けやすくなりました。

Eclipse Vert.x 4 以降では、POST requests BodyHandler を処理する必要があります。Eclipse Vert.x Web GraphQL ハンドラーをインストールする前に、BodyHandler をインストールする必要があります。

本リリース以前は、以下のメトリクスはソケットのディストリビューションサマリーとして記録されていました。Eclipse Vert.x 4 以降では、これらのメトリクスはカウンターとしてログに記録され、交換されたデータ量を報告します。

これらのカウンターでは、HTTP 用に同等のディストリビューションサマリーが導入されました。これらのサマリーは、要求および応答のサイズに関する情報を収集するために使用されます。

以下のメトリクスの名前が変更されました。

Vertx -web-openapi モジュールは RouterBuilder を使用して Eclipse Vert.x Web ルーターをビルドします。このルータービルダーは、vertx- web-api-contract モジュールのルータービルダー OpenAPI3RouterFactory と似ています。

Vertx -web-openapi モジュールの使用を開始するには、RouterBuilder をインスタンス化します。

RouterBuilder.create(vertx, "petstore.yaml").onComplete(ar -> {
  if (ar.succeeded()) {
    // Spec loaded with success
    RouterBuilder routerBuilder = ar.result();
  } else {
    // Something went wrong during router builder initialization
    Throwable exception = ar.cause();
  }
});

Future を使用して RouterBuilder をインスタンス化することもできます。

RouterBuilder.create(vertx, "petstore.yaml")
  .onSuccess(routerBuilder -> {
    // Spec loaded with success
  })
  .onFailure(exception -> {
    // Something went wrong during router builder initialization
  });

ほとんどの場合、古い OpenAPI3RouterFactory メソッド を検索して、新しい RouterBuilder メソッドに置き換えることができます。以下の表は、旧式のメソッドと新しいメソッドの例をいくつか紹介します。

以下の構文を使用して、解析された要求パラメーターにアクセスします。

RequestParameters parameters = routingContext.get(io.vertx.ext.web.validation.ValidationHandler.REQUEST_CONTEXT_KEY);
int aParam = parameters.queryParameter("aParam").getInteger();

Eclipse Vert.x 4 では、methodRouterFactory.addSecurityHandler（） および OpenAPI3RouterFactory.addSecuritySchemaScopeValidator（） が利用できなくなりました。

代わりに RouterBuilder.securityHandler（） メソッドを使用します。このメソッドは、io .vertx.ext.web.handler.AuthenticationHandler をハンドラーとして受け入れます。このメソッドは OAuth2Handler を自動的に認識し、セキュリティースキーマを設定します。

新しいセキュリティーハンドラーは、OpenAPI 仕様 で定義された操作も実装します。

Vertx -web-openapi モジュールでは、以下の失敗ハンドラーは利用できません。Router.errorHandler(int, Handler) メソッドを使用して失敗ハンドラーを設定する必要があります。

Eclipse Vert.x 4 では、OpenAPI コントラクトは、平文古い Java オブジェクト(POJO)にマップされません。そのため、追加の swagger-parser 依存関係は不要になりました。ゲッターおよびリゾルバーを使用して、コントラクトの特定のコンポーネントを取得できます。

以下の例は、1 つの操作を使用して特定のコンポーネントを取得する方法を示しています。

JsonObject model = routerBuilder.operation("getPets").getOperationModel();

以下の例は、完全なコントラクトを取得する方法を示しています。

JsonObject contract = routerBuilder.getOpenAPI().getOpenAPI();

以下の例は、コントラクトの一部を解決する方法を示しています。

JsonObject petModel = routerBuilder.getOpenAPI().getCached(JsonPointer.from("/components/schemas/Pet"));

Vertx -web-api-contract モジュールでは、HTTP RequestValidationHandler を使用して HTTP リクエストを検証できます。検証に OpenAPI を使用する必要はありません。

Eclipse Vert.x 4 では、HTTP 要求を検証するには vertx-web-validation モジュールを使用します。このモジュールをインポートし、OpenAPI を使用せずにリクエストを検証できます。ValidationHandler を使用して要求を検証します。

Vertx -web-api-service モジュールが更新され、vertx -web-validation モジュールとともに使用できるようになりました。Vertx -web-openapi モジュールを使用している場合、Web サービス機能は変更されません。

ただし、OpenAPI を使用しない場合は、vertx -web-validation モジュールで Web サービスモジュールを使用するには、RouteToEBServiceHandler クラスを使用する必要があります。

router.get("/api/transactions")
  .handler(
    ValidationHandlerBuilder.create(schemaParser)
      .queryParameter(optionalParam("from", stringSchema()))
      .queryParameter(optionalParam("to", stringSchema()))
      .build()
  ).handler(
    RouteToEBServiceHandler.build(eventBus, "transactions.myapplication", "getTransactionsList")
  );

Vertx -web-api-service モジュールは vertx-web-api-contract をサポートしません。そのため、Eclipse Vert.x 4 にアップグレードする場合は、Eclipse Vert.x OpenAPI アプリケーションを vertx-web-openapi モジュールに移行する必要があります。

以下のメソッドは future で使用できないため、CircuitBreaker クラス から削除されました。

Handler<AmqpMessage> を引数として 持つサービス検出で、以下の作成メソッドが削除されました。Future では、これらのメソッドは使用できません。

The ServiceDiscovery.registerServiceImporter（） メソッドおよび ServiceDiscovery.registerServiceExporter（） メソッドは fluent ではなくなりました。メソッドは Future<AsyncResult> を返します。

Vertx -service-discovery-bridge-kubernetes は KubernetesServiceImporter 検出ブリッジを追加します。ブリッジは、Kubernetes または Openshift から Eclipse Vert.x サービス検出にサービスをインポートします。

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

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

以下の例では、ブリッジを手動で登録する方法を説明します。

JsonObject defaultConf = new JsonObject();
serviceDiscovery.registerServiceImporter(new KubernetesServiceImporter(), defaultConf);

SecretOptions クラスは利用できなくなりました。代わりに new PubSecKeyOptions クラスを使用して、暗号化キーと連携します。

以下の例は、Eclipse Vert.x 3.x リリースで SecretOptions クラスのメソッドが使用される方法を示しています。

new SecretOptions()
    .setType("HS256")
    .setSecret("password")

以下の例は、Eclipse Vert.x 4 で PubSecKeyOptions クラスのメソッドを使用する方法を示しています。

new PubSecKeyOptions()
    .setAlgorithm("HS256")
    .setSecretKey("password")

Eclipse Vert.x 3.x では、公開秘密鍵管理の設定オブジェクトは以下を前提としています。

以下の例は、Eclipse Vert.x 3.x でキーペアを設定する方法を示しています。

new PubSecKeyOptions()
  .setPublicKey(
    // remove the PEM boundaries
    pubPemString
      .replaceAll("-----BEGIN PUBLIC KEY----")
      .replaceAll("-----END PUBLIC KEY----"))
  .setSecretKey(
    // remove the PEM boundaries
    secPemString
      .replaceAll("-----BEGIN PUBLIC KEY----")
      .replaceAll("-----END PUBLIC KEY----"));

Eclipse Vert.x 4 では、公開鍵と秘密鍵の両方を指定する必要があります。

以下の例は、Eclipse Vert.x 4 でキーペアを設定する方法を示しています。

PubSecKeyOptions pubKey =
  new PubSecKeyOptions()
    // the buffer is the exact contents of the PEM file and had boundaries included in it
    .setBuffer(pubPemString);

PubSecKeyOptions secKey =
  new PubSecKeyOptions()
    // the buffer is the exact contents of the PEM file and had boundaries included in it
    .setBuffer(secPemString);

PubSecKeyOptions を使用して X509 証明書に対応できるようになりました。

PubSecKeyOptions x509Certificate =
  new PubSecKeyOptions()
    // the buffer is the exact contents of the PEM file and had boundaries included in it
    .setBuffer(x509PemString);

Eclipse Vert.x 3.x では、KeyStore Options はキーストアの形式が jceks であると仮定し、保存されたパスワードはキーのパスワードと同じであることを前提としています。Jceks はプロプライエタリー形式であるため、代わりに JDK などの標準形式を使用することが推奨されます。

Eclipse Vert.x 4 で KeyStoreOptions を使用する場合は、ストアタイプを指定できます。たとえば、PKCS11 や PKCS12 などのストアタイプを設定できます。デフォルトのストアタイプは jceks です。

Eclipse Vert.x 3.x では、すべてのキーストアエントリーが同じパスワード（キーストアパスワード）を共有します。Eclipse Vert.x 4 では、各キーストアエントリーに専用のパスワードを指定できます。各キーストアエントリーにパスワードを設定しない場合は、キーストアパスワードをすべてのエントリーのデフォルトパスワードとして設定できます。

以下の例は、Eclipse Vert.x 3.x で jceks キーストアを読み込む方法を示しています。

new KeyStoreOptions()
  .setPath("path/to/keystore.jks")
  .setPassword("keystore-password");

Eclipse Vert.x 4 では、デフォルトの形式は JDK によって設定されるデフォルトの形式であることを前提としています。形式は、Java 9 以降の PKCS12 です。

以下の例は、Eclipse Vert.x 4 で jceks キーストアを読み込む方法を示しています。

new KeyStoreOptions()
  .setPath("path/to/keystore.jks")
  // Modern JDKs use `jceks` keystore. But this type is not the default
  // If the type is not set to `jceks` then probably `pkcs12` will be used
  .setType("jceks")
  .setPassword("keystore-password")
  // optionally if your keys have different passwords
  // and if a key specific id is not provided it defaults to
  // the keystore password
  .putPasswordProtection("key-id", "key-specific-password");

以下のメソッドが削除されました。

以下のメソッドが非推奨になりました。

以下のクラスが非推奨になりました。

Eclipse Vert.x 4 では、protoc-gen-grpc-java モジュールは利用できなくなりました。このモジュールは、公式の gRPC コンパイラーのフォークです。以前のリリースの Eclipse Vert.x では、このフォークを使用して作業する必要がありました。このフォークは Eclipse プロジェクトにより維持されます。フォークの使用は複雑です。

以前のリリースでは、gRPC を使用するために、以下の情報が pom.xml ファイルに追加されていました。

  <!-- Vert.x 3.x -->
<plugin>
  <groupId>org.xolstice.maven.plugins</groupId>
  <artifactId>protobuf-maven-plugin</artifactId>
  <configuration>
    <protocArtifact>com.google.protobuf:protoc:3.2.0:exe:${os.detected.classifier}</protocArtifact>
    <pluginId>grpc-java</pluginId>
    <!-- NOTE: the gav coordinates point to the 3.x only compiler fork -->
    <pluginArtifact>io.vertx:protoc-gen-grpc-java:${vertx.grpc.version}:exe:${os.detected.classifier}</pluginArtifact>
  </configuration>
  ...
</plugin>

Eclipse Vert.x 4 では、新しい gRPC コンパイラープラグインが利用できるようになりました。このプラグインは、フォークの代わりに公式の gRPC コンパイラーを使用します。新しい gRPC プラグインを使用するには、以下の情報を pom.xml ファイルに追加します。

    <!-- Vert.x 4.x -->
<plugin>
  <groupId>org.xolstice.maven.plugins</groupId>
  <artifactId>protobuf-maven-plugin</artifactId>
  <configuration>
    <protocArtifact>com.google.protobuf:protoc:3.2.0:exe:${os.detected.classifier}</protocArtifact>
    <pluginId>grpc-java</pluginId>
    <!-- NOTE: the gav coordinates point to the official compiler -->
    <pluginArtifact>io.grpc:protoc-gen-grpc-java:${vertx.grpc.version}:exe:${os.detected.classifier}</pluginArtifact>
    <protocPlugins>
      <!-- NEW: a plugin is added to generate the Vert.x specific code -->
      <protocPlugin>
        <id>vertx-grpc-protoc-plugin</id>
        <groupId>io.vertx</groupId>
        <artifactId>vertx-grpc-protoc-plugin</artifactId>
        <version>${vertx.version}</version>
        <mainClass>io.vertx.grpc.protoc.plugin.VertxGrpcGenerator</mainClass>
      </protocPlugin>
    </protocPlugins>
  </configuration>
  ...
</plugin>

Eclipse Vert.x 4 では、新しいコンパイラーが使用されます。新規の gRPC プラグインが使用されると、生成されたコードは同じソースファイルに書き込まれません。これは、コンパイラーがベースクラスでのカスタムコード生成を許可しないためです。コードを保存するには、プラグインが別の名前で新しいクラスを生成する必要があります。

以前のリリースの Eclipse Vert.x では、古い gRPC プラグインが同じソースファイルに生成されたコードを書き込みました。

たとえば、以下の記述子があるとします。

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

Eclipse Vert.x 3.x では、コードは GreeterGrpc クラスに生成されます。

// 3.x
GreeterGrpc.GreeterVertxImplBase service =
  new GreeterGrpc.GreeterVertxImplBase() {
      ...
  }

Eclipse Vert.x 4 では、コードは VertxGreeterGrpc クラスに生成されます。

// 4.x
VertxGreeterGrpc.GreeterVertxImplBase service =
  new VertxGreeterGrpc.GreeterVertxImplBase() {
      ...
  }

Eclipse Vert.x 4 では、gRPC API は future をサポートします。GRPC プラグインはプロミスキャス化された API を生成します。これらの API は標準の Eclipse Vert.x の入力引数および出力引数を使用するため、標準の Eclipse Vert.x アプリケーションの作成が容易になります。

以下の例は、Eclipse Vert.x 3.x での promise の使用例を示しています。

// 3.x
GreeterGrpc.GreeterVertxImplBase service =
  new GreeterGrpc.GreeterVertxImplBase() {
        @Override
        public void sayHello(HelloRequest request, Promise<HelloReply> future) {
          future.complete(
              HelloReply.newBuilder().setMessage(request.getName()).build());
        }
  }

以下の例は、Eclipse Vert.x 4 での future の使用を示しています。

// 4.x
VertxGreeterGrpc.GreeterVertxImplBase service =
  new VertxGreeterGrpc.GreeterVertxImplBase() {
      @Override
      public Future<HelloReply> sayHello(HelloRequest request) {
        return Future.succeededFuture(
          HelloReply.newBuilder()
            .setMessage(request.getName())
            .build());
      }
  }

MqttClient クラスの fluent メソッドの一部は、fluent ではなく Future を返します。たとえば、MqttClient. connect（）、MqttClient.disconnect（）、MqttClient. publish（） などのメソッドは、Eclipse Vert.x 4 の future を返します。

以下の例は、Eclipse Vert.x 3.x リリースでの publish（） メソッドの使用を示しています。

client
   .publish("hello", Buffer.buffer("hello"), MqttQoS.EXACTLY_ONCE, false, false)
   .publish("hello", Buffer.buffer("hello"), MqttQoS.AT_LEAST_ONCE, false, false);

以下の例は、Eclipse Vert.x 4 リリースでの publish（） メソッドの使用を示しています。

client.publish("hello", Buffer.buffer("hello"), MqttQoS.EXACTLY_ONCE, false, false);
client.publish("hello", Buffer.buffer("hello"), MqttQoS.AT_LEAST_ONCE, false, false);

MqttWill データオブジェクトは、文字列メッセージをバイトアレイではなく Eclipse Vert.x バッファーとしてラップします。

以下の MQTT メソッドが削除されました。

ServiceProxyProcessor クラスが削除されました。

サービスプロキシーコードジェネレーターを使用するには、クラスパスのプロセッサー分類 子で vertx-codegen をインポートする必要があります。

<dependencies>
  <dependency>
    <groupId>io.vertx</groupId>
    <artifactId>vertx-codegen</artifactId>
    <classifier>processor</classifier>
  </dependency>
  <dependency>
    <groupId>io.vertx</groupId>
    <artifactId>vertx-service-proxy</artifactId>
  </dependency>
</dependencies>

サービスプロキシーは vertx-codegen から io.vertx.codegen.CodeGenProcessor を再利用して、サービスプロキシーおよびハンドラーのコード生成を開始します。

AdminUtils クラスが利用できなくなりました。代わりに新しい KafkaAdminClient クラスを使用して、Kafka クラスターで管理操作を実行します。

KafkaProducer クラスのフラッシュメソッドは、Handler<AsyncResult> の代わりに Handler<AsyncResult<AsyncResult>& gt; を使用します。

Eclipse Vert.x 4 では、JDBC クライアント API を使用してプールを作成できます。以前のリリースでは、クライアントのみを作成できました。プールを作成できませんでした。

以下の例は、Eclipse Vert.x 3.x でクライアントを作成する方法を示しています。

// 3.x
SQLClient client = JDBCClient.create(vertx, jsonConfig);

以下の例は、Eclipse Vert.x 4 でプールを作成する方法を示しています。

// 4.x
JDBCPool pool = JDBCPool.pool(vertx, jsonConfig);

プールを使用すると、単純なクエリーを実行できます。単純なクエリーの接続を管理する必要はありません。ただし、複雑なクエリーや複数のクエリーの場合は、接続を管理する必要があります。

以下の例は、Eclipse Vert.x 3.x でクエリーの接続を管理する方法を示しています。

// 3.x
client.getConnection(res -> {
  if (res.succeeded()) {
    SQLConnection connection = res.result();
    // Important, do not forget to return the connection
    connection.close();
  } else {
    // Failed to get connection
  }
});

以下の例は、Eclipse Vert.x 4 でクエリーの接続を管理する方法を示しています。

// 4.x
pool
  .getConnection()
  .onFailure(e -> {
    // Failed to get a connection
  })
  .onSuccess(conn -> {
    // Important, do not forget to return the connection
    conn.close();
  });

設定には jsonConfig を使用できます。ただし、jsonConfig を使用するとエラーが発生する可能性があります。これらのエラーを回避するには、JDBC クライアントでは Typesafe Config が導入されました。

以下の例は、Typesafe Config の基本構造を示しています。

// 4.x ONLY!!!
JDBCPool pool = JDBCPool.pool(
      vertx,
      // configure the connection
      new JDBCConnectOptions()
        // H2 connection string
        .setJdbcUrl("jdbc:h2:~/test")
        // username
        .setUser("sa")
        // password
        .setPassword(""),
      // configure the pool
      new PoolOptions()
        .setMaxSize(16)
    );

ここでは、JDBC クライアントでクエリーを実行する方法を説明します。

// 3.x
client.query("SELECT * FROM user WHERE emp_id > ?", new JsonArray().add(1000), res -> {
  if (res.succeeded()) {
    ResultSet rs = res2.result();
    // You can use these results in your application
  }
});

// 4.x
pool
  .preparedQuery("SELECT * FROM user WHERE emp_id > ?")
  // the emp id to look up
  .execute(Tuple.of(1000))
  .onSuccess(rows -> {
    for (Row row : rows) {
      System.out.println(row.getString("FIRST_NAME"));
    }
  });

pool
  .getConnection()
  .onFailure(e -> {
    // Failed to get a connection
  })
  .onSuccess(conn -> {
    conn
      .query("SELECT * FROM user")
      .execute()
      .onFailure(e -> {
        // Handle the failure
        // Important, do not forget to return the connection
        conn.close();
      })
      .onSuccess(rows -> {
        for (Row row : rows) {
          System.out.println(row.getString("FIRST_NAME"));
        }
        // Important, do not forget to return the connection
        conn.close();
      });
  });

ストアドプロシージャーは JDBC クライアントでサポートされます。

以下の例は、Eclipse Vert.x 3.x で IN 引数を渡す方法を示しています。

// 3.x
connection.callWithParams(
  "{ call new_customer(?, ?) }",
  new JsonArray().add("John").add("Doe"),
  null,
  res -> {
    if (res.succeeded()) {
      // Success!
    } else {
      // Failed!
    }
  });

以下の例は、Eclipse Vert.x 4 で IN 引数を渡す方法を示しています。

// 4.x
client
  .preparedQuery("{call new_customer(?, ?)}")
  .execute(Tuple.of("Paulo", "Lopes"))
  .onSuccess(rows -> {
    ...
  });

Eclipse Vert.x 3.x では、IN 引数と OUT 引数を組み合わせるサポートは、利用可能なタイプにより大幅に制限されていました。Eclipse Vert.x 4 では、プールは安全なタイプであり、IN と OUT 引数の組み合わせを 処理できます。アプリケーションで INOUT パラメーターを使用することもできます。

以下の例は、Eclipse Vert.x 3.x での引数の処理を示しています。

// 3.x
connection.callWithParams(
  "{ call customer_lastname(?, ?) }",
  new JsonArray().add("John"),
  new JsonArray().addNull().add("VARCHAR"),
  res -> {
    if (res.succeeded()) {
      ResultSet result = res.result();
    } else {
      // Failed!
    }
});

以下の例は、Eclipse Vert.x 4 での引数の処理を示しています。

// 4.x
client
  .preparedQuery("{call customer_lastname(?, ?)}")
  .execute(Tuple.of("John", SqlOutParam.OUT(JDBCType.VARCHAR)))
  .onSuccess(rows -> {
    ...
  });

JDBC クライアントで、データタイプが更新されました。

Eclipse Vert.x 4 以降では、MailAttachment はインターフェースとして利用できます。これにより、ストリームでメール添付機能を使用できます。以前のリリースの Eclipse Vert.x では、MailAttachment はクラスとして利用でき、メールの添付ファイルはデータオブジェクトとして表されていました。

MailConfig インターフェースは NetClientOptions インターフェースを拡張します。この拡張機能により、メール設定は NetClient のプロキシー設定もサポートします。

Handler<AmqpMessage> を引数として持つ AMQP クライアントメソッドが削除されました。以前のリリースでは、このハンドラーを ReadStream<AmqpMessage> に設定できました。ただし、アプリケーションを移行して future を使用する場合、このような方法は使用できません。

以下のメソッドは MongoClient クラスから削除されました。

Eclipse Vert.x 4 より前は、すべての Eclipse Vert.x リリースに JavaScript クライアントの新しいリリースが含まれていました。

ただし、Eclipse Vert.x 4 以降では、クライアントに変更がある場合に限り、新しいバージョンの JavaScript クライアントを npm で利用できます。バージョンの変更がない限り、すべての Eclipse Vert.x リリースでクライアントアプリケーションを更新する必要はありません。

既存のアプリケーションを新しい Redis クライアントに直接移行するか、またはヘルパークラス RedisAPI を使用して 2 つの手順でアプリケーションを移行できます。

アプリケーションを移行する前に、クライアントを作成する必要があります。

// Create the redis client (3.x)
RedisClient client = RedisClient
  .create(vertx, new RedisOptions().setHost(host));

// Create the redis client (4.x)
Redis client = Redis
  .createClient(
    vertx,
    "redis://server.address:port");

redis[s]://[[user]:password@]server[:port]/[database]

// Using 3.x
// omitting the error handling for brevity
client.set("key", "value", s -> {
  if (s.succeeded()) {
    System.out.println("key stored");
    client.get("key", g -> {
      if (s.succeeded()) {
        System.out.println("Retrieved value: " + s.result());
      }
    });
  }
});

// Using 4.x
// omitting the error handling for brevity

// 1. Wrap the client into a RedisAPI
api = RedisAPI.api(client);

// 2. Use the typed API
api.set(
    Arrays.asList("key", "value"), s -> {
    if (s.succeeded()) {
      System.out.println("key stored");
      client.get("key", g -> {
        if (s.succeeded()) {
          System.out.println("Retrieved value: " + s.result());
        }
      });
    }
});

// Using 3.x
// omitting the error handling for brevity
client.set("key", "value", s -> {
  if (s.succeeded()) {
    System.out.println("key stored");
    client.get("key", g -> {
      if (s.succeeded()) {
        System.out.println("Retrieved value: " + s.result());
      }
    });
  }
});

// Using 4.x
// omitting the error handling for brevity

import static io.vertx.redis.client.Request.cmd;
import static io.vertx.redis.client.Command.*;

client.send(cmd(SET).arg("key").arg("value"), s -> {
    if (s.succeeded()) {
      System.out.println("key stored");
      client.send(cmd(GET).arg("key"), g -> {
        if (s.succeeded()) {
          System.out.println("Retrieved value: " + s.result());
        }
      });
    }
});

// Using 4.x
// omitting the error handling for brevity

import static io.vertx.redis.client.Request.cmd;
import static io.vertx.redis.client.Command.*;

client.send(cmd(MGET).arg("key1").arg("key2").arg("key3"), mget -> {
  mget.result()
    .forEach(value -> {
      // Use the single value

本セクションでは、Redis クライアントの変更点を説明します。

// Before (3.x)
Redis.createClient(
      rule.vertx(),
      new RedisOptions()
        .setType(RedisClientType.SENTINEL)
        .addConnectionString("redis://localhost:5000")
        .setMasterName("sentinel7000")
        .setRole(RedisRole.SLAVE));

// After (4.x)
Redis.createClient(
      rule.vertx(),
      new RedisOptions()
        .setType(RedisClientType.SENTINEL)
        .addConnectionString("redis://localhost:5000")
        .setMasterName("sentinel7000")
        .setRole(RedisRole.REPLICA));

// Before (3.9)
options.setUseSlaves(RedisSlaves);

// After (4.x)
options.setUseReplicas(RedisReplicas);

Infinispan クラスターマネージャーは Infinispan 12 をベースとしています。

Eclipse Vert.x 4 では、クラスタリング SPI が再設計されました。サブスクリプションのデータモデルが変更されました。そのため、Eclipse Vert.x 3.x ノードと Eclipse Vert.x 4 ノードを同じ Infinispan クラスターに追加することはできません。

EventBus API および SharedData API が同じままであるため、Eclipse Vert.x アプリケーションはこの変更の影響を受けません。

Eclipse Vert.x 3.x アプリケーションでカスタム Infinispan 設定ファイルがある場合：

 <cache-container default-cache="distributed-cache">
    <distributed-cache name="distributed-cache"/>
    <replicated-cache name="__vertx.subs"/>
    <replicated-cache name="__vertx.haInfo"/>
    <replicated-cache name="__vertx.nodeInfo"/>
    <distributed-cache-configuration name="__vertx.distributed.cache.configuration"/>
  </cache-container>

Openshift で Eclipse Vert.x クラスターを実行する場合、infinispan -cloud JAR は不要になりました。JAR はビルドファイルの dependencies セクションから削除されます。この JAR にバンドルされた設定ファイルは infinispan-core JAR に含まれるようになりました。

アプリケーションごとに異なるチームが verticle をデプロイしたクラスターがある場合、Eclipse Vert.x 3.x クラスターを小規模なものに分割することを検討してください。クラスターを分割すると、分離されたコンポーネントはクラスタリング機能を使用して通信できなくなることに注意してください。以下のコンポーネントを使用してクラスターを分割できます。

クラスターの分割後に、各チームの準備が整ったら、または必要に応じて Eclipse Vert.x 4 に移行できます。

クラスターを分割できない場合は、Vert.x EventBus リンク を使用してコードベースを段階的に移行します。

Vert.x EventBus Link は、Eclipse Vert.x 3.x クラスター EventBus を Eclipse Vert.x 4 クラスター EventBus に接続するツールです。

このツールは、EventBus インターフェースを実装する EventBus Link オブジェクトを作成します。EventBusLink のインスタンスは、各クラスターの少なくとも 1 つのノードに作成されます。インスタンスは、アドレスのセットを提供し、その動作はメッセージのパラダイムによって異なります。

Eclipse Vert.x EventBus リンクは、WebSocket サーバーを作成してメッセージを受信し、WebSocket クライアントを使用してメッセージを送信します。

詳細は、「 Getting started」 および「 using 」を参照してください。

Vertx -core モジュールが更新され、パラメーターの挿入にサービスプロバイダーインターフェースが使用されるようになりました。この変更により、JUnit5 に以下の更新が行われました。

VertxTestContext.succeeding（） メソッドおよび VertxTestContext.failing（） メソッドが非推奨になりました。代わりに VertxTestContext.succeedingThenComplete（） メソッドおよび VertxTestContext.failingThenComplete（） メソッドを使用してください。