-
Notifications
You must be signed in to change notification settings - Fork 35
4.5.0 Deprecations and breaking changes
https://github.com/eclipse-vertx/vert.x/pull/4916
The DeploymentOptions#setWorker and DeploymentOptions#getWorker methods are deprecated since ThreadingModel replaces them.
// Before
Future<String> f = vertx.deployVerticle(new DeploymentOptions().setWorker(true, ...)
// After
Future<String> f = vertx.deployVerticle(new DeploymentOptions().setThreadingModel(ThreadingModel.WORKER, ...)https://github.com/eclipse-vertx/vert.x/pull/4853
The Vert.x HttpClient WebSocket connect methods have been deprecated since they are moved in Vert.x 5 to a new WebSocketClient interface.
// Before
HttpClient httpClient = vertx.createHttpClient();
Future<WebSocket> f = httpClient.webSocket(connectOptions);
// After
WebSocketClient wsClient = vertx.createWebSocketClient();
Future<WebSocket> f = wsClient.connect(connectOptions);https://github.com/eclipse-vertx/vert.x/pull/4853
The Vert.x HttpClient redirectHandler/connectionHandler`` methods have been deprecated since they are moving in Vert.x 5 to a HttpClientBuilderinterface.HttpClientBuilderis a builder object that configures and creates HTTP clients which is now returned byVertx#httpClientBuilder` methods.
// Before
HttpClient client = vertx.createHttpClient();
client.connectionHandler(conn -> ...);
// After
HttpClientBuilder builder = vertx.httpClientBuilder();
builder.withConnectionHandler(conn -> ...);
HttpClient client = builder.build();https://github.com/eclipse-vertx/vert.x/pull/4937
The request timeout is actually an idle timeout and we should rename this method to avoid confusion.
// Before
client.request(options).onComplete((HttpClientRequest request) -> {
request.setTimeout(timeout);
...
});
// After
client.request(options).onComplete((HttpClientRequest request) -> {
request.idleTimeout(timeout);
...
});https://github.com/eclipse-vertx/vert.x/pull/4940
The updateSSLOptions(SSLOptions) methods used to return a Future<Void>, given that the update might work but not happen (because the options are the same), returning a Future<Boolean> is more appropriate since now there is a parameter to force the update.
// Before
Future<Void> fut = server.updateSSLOptions(newOptions);
// After
Future<Boolean> fut = server.updateSSLOptions(newOptions);https://github.com/eclipse-vertx/vertx-sql-client/pull/1357
The Pool subtypes are not really useful as they don't carry any extra method and are use mainly for statically building pool. In addition those static methods are not flexible and are numerous due to overloading. We are replacing these methods with a client builder API.
// Before
PgPool client = PgPool.pool(vertx, connectOptions, poolOptions);
//After
Pool client = PgBuilder.pool()
.with(poolOptions)
.connectingTo(connectOptions)
.using(vertx)
.build()The Pool#connectHandler method has been deprecated and is replaced by a corresponding method on the new ClientBuilder.
// Before
pool.connectHandler(conn -> ...);
// After
builder.connectHandler(conn -> ...);The Pool#connectionProvider method has been deprecated and is replaced by the Supplier<Future<SqlConnectOptions>> method.
// Before
pool.connectionProvider(ctx -> futureOfSqlConnection(ctx));
// After
builder.connectingTo(() -> futureOfSqlConnectOptions());The supplier will be called by the pool when a connection is required and use the connect options to handle the connection part.
https://github.com/eclipse-vertx/vert.x/pull/4929
The client tryUseCompression option was misleading to many as it implied that the client would try to compress the request payload but, actually, it meant that it would send a request with an accepting-encoding header set to a compression algorithm, to tell the server that it supports a compressed response.
// Before
httpClientOptions.setTryUseCompression(true);
// After
httpClientOptions.setDecompressionSupported(true);https://github.com/vert-x3/vertx-web/pull/2503
Before that change, uploads were unlimited by default, which is not sensible from a security perspective.
https://github.com/vert-x3/vertx-web/pull/2496
Many web handlers failures were signaled with an HTTP status code together with an IllegalStateException, for informational purposes.
But ISE creates a stack trace which isn't really useful. In these cases, we only care about the message.
This change makes the application log a single line (or more if the message is long). Besides, it saves the cost of creating the stack trace of the ISE.
https://github.com/vert-x3/vertx-web/issues/2509
WebClientOptions extends HttpClientOptions and had to be changed like its parent class.
// Before
webClientOptions.setTryUseCompression(true);
// After
webClientOptions.setDecompressionSupported(true);https://github.com/vert-x3/vertx-web/issues/2510
CachingWebClientOptions extends WebClientOptions and had to be changed like its parent class.
// Before
cachingWebClientOptions.setTryUseCompression(true);
// After
cachingWebClientOptions.setDecompressionSupported(true);https://github.com/vert-x3/vertx-lang-kotlin/issues/258
With Loom support in Vert.x 4.5, there is a Future.await() method in Vert.x core (see eclipse-vertx/vert.x#4916).
The Vert.x Kotlin Coroutines Future.await() extension method is no longer applicable and we need a new name for it, Future.coAwait().
val future = doSomethingAsync()
// Before
future.await()
// After
future.coAwait()https://github.com/vert-x3/vertx-mqtt/pull/246
The payload willMessage was stored in the MqttClientOptions as a string and afterwards converted to bytes, assuming UTF-8 encoding.
Now the payload is stored a Vert.x Buffer, and it's the user's responsibility to convert from a string if necessary, using the right encoding.
// Before
mqttClientOptions.setWillMessage("the-message");
// After
mqttClientOptions.setWillMessageBytes(Buffer.buffer("the-message", "UTF-16"));https://github.com/eclipse-vertx/vertx-tracing/issues/65
HttpSenderOptions extends HttpClientOptions and had to be changed like its parent class.
// Before
httpSenderOptions.setTryUseCompression(true);
// After
httpSenderOptions.setDecompressionSupported(true);