-
Notifications
You must be signed in to change notification settings - Fork 35
5.0.0 Deprecations and breaking changes
A few system properties have been removed in Vert.x 5:
-
vertx.json.base64is removed: Vert.x 3.x Json supports RFC-7493, however the JSON encoder/decoder format was incorrect. Users who needed to interop with Vert.x 3.x applications should have set the system propertyvertx.json.base64tolegacy. -
vertx.cluster.managerClassis removed: not used, neither documented nor tested -
vertx.javaCompilerOptionsis removed: not used, neither documented nor tested -
vertx.disableTCCLis removed: insteadVertxOptions#setDisableTCCL(boolean)should be used -
vertx.disableHttpHeadersValidationis deprecated
The HTTP/2 connection shutdown handler notifies the handler when the connection shutdown begins, previously the handler was notified when after all the connection streams have been closed.
This allows to be aware of a connection shutdown and take appropriate measures to stop the inflight streams being processed. It also aligns with the behaviour of other shutdown handlers.
The HttpConnection#shutdown(long) has been removed, instead HttpConnection#shutdown(long, TimeUnit) should be used.
// 4.x
connection.shutdown(5 * 1000); // 5 seconds
// 5.0
connection.shutdown(5, TimeUnit.SECONDS); // 5 secondshttps://github.com/eclipse-vertx/vert.x/pull/5077
The default stream byte distributor use stream priorities to determine the amount of bytes to be sent for each stream, this change allows to use a strategy that does not use stream priorities and yields better performance since it consumes less CPU.
The default implementation is now UniformStreamByteDistributor instead of WeightedFairQueueByteDistributor .
https://github.com/eclipse-vertx/vert.x/pull/4916
-
VertxOptions#setClusterManageris removed, instead use the newVertxBuilder
// 4.x
Future<Vertx> f = Vertx.clusteredVertx(new VertxOptions().setClusterManager(clusterManager));
// 5.0
Future<Vertx> f = Vertx.builder().withClusterManager(clusterManager).buildClustered();-
MetricsOptions#setFactoryis removed, instead use the newVertxBuilder
// 4.x
Vertx vertx = Vertx.vertx(new VertxOptions().setMetricsOptions(new MetricsOptions().setEnabled(true).setFactory(factory)));
// 5.0
Vertx vertx = Vertx.builder().withMetrics(factory).build();-
TracingOptions#setFactoryis removed, instead use the newVertxBuilder
// 4.x
Vertx vertx = Vertx.vertx(new VertxOptions().setTracingOptions(new TracingOptions().setFactory(factory)));
// 5.0
Vertx vertx = Vertx.builder().withTracing(factory).build();https://github.com/eclipse-vertx/vert.x/pull/4938
The request timeout is actually an idle timeout and we should rename this method to avoid confusion.
// 4.x
request.setTimeout(timeout);
// 5.0
request.setIdleTimeout(timeout);https://github.com/eclipse-vertx/vert.x/pull/4918
The DeploymentOptions#setWorker and DeploymentOptions#getWorker methods are removed since ThreadingModel replaces them.
// 4.x
Future<String> f = vertx.deployVerticle(new DeploymentOptions().setWorker(true, ...)
// 5.0
Future<String> f = vertx.deployVerticle(new DeploymentOptions().setThreadingModel(ThreadingModel.WORKER, ...)https://github.com/eclipse-vertx/vert.x/pull/4863
The Vert.x HttpClient WebSocket connect methods are moved to a new WebSocketClient interface.
// 4.x
HttpClient httpClient vertx.createHttpClient();
Future<WebSocket> f = httpClient.webSocket(connectOptions);
// 5.0
WebSocketClient wsClient vertx.createWebSocketClient();
Future<WebSocket> f = wsClient.connect(connectOptions);https://github.com/eclipse-vertx/vert.x/pull/4863
The Vert.x HttpClient redirectHandler/connectionHandler/updateSSLOptions are moving to a HttpClientPool interface. HttpClientPool is a new interface exiting HttpClient which is now returned by Vertx#createHttpClient methods.
// 4.x
HttpClient client = vertx.createHttpClient();
client.connectionHandler(conn -> ...);
// 5.0
HttpClientPool client = vertx.createHttpClient();
client.connectionHandler(conn -> ...);https://github.com/eclipse-vertx/vert.x/pull/4806
The HttpServerResponse close method closes the HTTP connection, it can be misleading as there are better API to interact with the current request/connection lifecycle which are HttpServerResponse#reset and HttpConnection#close.
When the actual HTTP connection must be closed:
// 4.x
response.close();
// 5.0
request.connection().close();When the current request/response must be disposed:
// 4.x
response.close();
// 5.0
response.reset();The Vert.x API exposes the Netty API in its public API, allowing interactions with the Netty API. Since Netty is evolving toward Netty 5, we should remove Netty API from the Vert.x public API in Vert.x 5 to have the opportunity to change the underlying Netty version used by Vert.x without worrying about the version of the Netty version.
Such API continues to exist in Vert.x 5 but is moved to internal API which more easily change, therefore experimented users of this API can continue to use it granted that the version of Vert.x 5 uses Netty 4.
In practice most users should not use this API, and the deprecation should be seen also as a signal toward users of this API.
// 4.x
ByteBuf bb = buff.getByteBuf();
Buffer buf = Buffer.buffer(bb);
EventLoopGroup group = vertx.nettyEventLoopGroup();
// 5.0
bb = ((BufferInternal)buff).getByteBuf();
buf = BufferInternal.buffer(bb);
group = ((VertxInternal)vertx).nettyEventLoopGroup();https://github.com/eclipse-vertx/vert.x/pull/4782
The Vert.x API for executing blocking actions uses a pattern with handler completing or failing a promise, instead this can be replaced with java.util.concurrent.Callable that returns the same value or throws an exception.
// 4.x
Future<String> fut = vertx.executeBlocking(promise -> promise.complete("result"));
// 5.0
Future<String> fut = vertx.executeBlocking(() -> "result");A few HTTP stream writeXXX API are fluent and instead should return a future signaling the success or failure of the write operation
https://github.com/eclipse-vertx/vert.x/pull/4779
This change breaks the fluent return, e.g
// 4.x
response.writeCustomFrame(12, 134, expectedRecv).end();
// 5.0
response.writeCustomFrame(12, 134, expectedRecv);
response.end();The HttpClientRequest/HttpServerRequest exposes the HTTP request authority using a host/port combination for the client request and a single host header for the server. In addition this terminology is also confusing with the server host and port.
Deprecate and provide the request host/port accessors, replaced by an authority property modelled as an @HostAndPort` object.
For client:
HttpClientRequest request = ...
// 4.x
request.setHost(host).setPort(port);
// 5.0
request.authority(HostAndPort.create(host, port));For server:
// 4.x
String host = request.host(); // host:port actually
// 5.0
HostAndPort authority = request.authority();The CompositeFuture methods use raw Future types, e.g all(Future,Future) or all(List<Future>>), such declarations force the user to cast when using a List<Future<Something>>. Such methods have been made fully generic, using the wildcard type.
List<Future<User>> users = ...
// 4.x
CompositeFuture cf = CompositeFuture.all((List<Future>)users);
// 5.0
CompositeFuture cf = Future.all(users);https://github.com/eclipse-vertx/vert.x/pull/4689
The HttpServer#requestStream() and HttpServer#timeoutStream() have been removed. These streams were designed for Rx like languages and the actually don't provide much benefits at the expense of the API.
// 4.x
server.requestStream().handler(request -> ...);
// 5.0
server.requestHandler(request -> ...).listen();https://github.com/eclipse-vertx/vert.x/pull/4689
The NetServer#connectStream() has been removed. This stream was designed for Rx like languages and the actually don't provide much benefits at the expense of the API.
// 4.x
server.connectStream().handler(socket -> ...);
// 5.0
server.connectHandler(socket -> ...).listen();https://github.com/eclipse-vertx/vert.x/pull/4689
The TimeoutStream has been removed. This streams was designed for Rx like languages and the actually don't provide much benefits at the expense of the API. Instead the framework scheduler should be used instead along with a Vert.x context.
// 4.x
vertx.periodicStream(1L).handler(timerID -> ...);
// 5.0
server.setPeriodic(1L, timerID -> ...);As for RxJava like integrations
// 4.x
Observable<Long> timer = vertx.periodicStream(1000).toObservable();
// 5.0
Scheduler scheduler = RxHelper.scheduler(vertx);
Observable<Long> timer = Observable.interval(100, 100, TimeUnit.MILLISECONDS, scheduler);https://github.com/eclipse-vertx/vert.x/pull/4695
The KeyCertOptions#keyManagerMapper() method has been removed in Vert.x 5, implementors must instead implement keyManagerFactoryMappermethod that provides the opportunity to cache the KeyManagerFactory to the implementor that controls the lifecycle of the key manager.
https://github.com/vert-x3/issues/issues/615
The vertx command-line tool has been removed in Vert.x 5.
We want to focus on the use case of the typical Vert.x application: compiled and optionally packaged as an executable uber-jar.
https://github.com/eclipse-vertx/vert.x/pull/4828
The Vertx Future#eventually method takes as parameter a Function<Void, Future<T>>, this was developed for codegen which did not support Supplier. The Future object is not code generated anymore since Vert.x 4, we can therefore use Supplier which is more suitable.
// 4.x
future.eventually(v -> someFuture());
// 5.0
future.eventually(() -> someFuture());https://github.com/vert-x3/issues/issues/615
The CLI framework is deprecated in Vert.x 5 and the code has been moved from the Vert.x core module to a new module, vertx-launcher-legacy-cli.
If your application depends on the CLI framework, please evaluate alternatives (like Picocli) as soon as possible.
In the meantime, you can preserve functionality by adding this dependency to your project (Maven):
<dependency>
<groupId>io.vertx</groupId>
<artifactId>vertx-launcher-legacy-cli</artifactId>
<version>5.0.0</version>
</dependency>
https://github.com/eclipse-vertx/vert.x/pull/4769
The io.vertx.core.Context#processArgs and io.vertx.core.AbstractVerticle#processArgs methods are deprecated.
As of version 5, Vert.x is no longer tightly coupled to the CLI.
https://github.com/eclipse-vertx/vert.x/issues/4817
Vert.x HTTP/1.1 server contains an hidden option to detect Adobe Flash clients and return a policy file response (http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html).
This option is activated by a system property vertx.flashPolicyHandler only referenced in source code (private field) and not tested.
https://github.com/eclipse-vertx/vert.x/pull/4826
This system property was not documented and only used in vertx-examples repository.
https://github.com/eclipse-vertx/vertx-sql-client/pull/1353
SqlConnectOptions do extend NetClientOptions which eventually leads to use a TCP client per socket forcing to keep a map of clients in the connection factory. We should avoiding this design and instead move the relevant bits of NetClientOptions to SqlConnectOptions like the new ClientSSLOptions.
Configuring SSL certificates at the connection level should use a ClientSSLOptions object instead of being directly configured on the connect options:
// 4.x
connectOptions.setTrustOptions(trustOptions);
// 5.0
connectOptions.setSslOptions(new ClientSSLOptions().setTrustOptions(trustOptions));https://github.com/eclipse-vertx/vertx-sql-client/pull/1354
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.
// 4.x
PgPool client = PgPool.pool(vertx, connectOptions, poolOptions);
//5.0
Pool client = PgBuilder.pool()
.with(poolOptions)
.connectingTo(connectOptions)
.using(vertx)
.build()The Pool#connectHandler method has been removed and is replaced by a corresponding method on the new ClientBuilder.
// 4.x
pool.connectHandler(conn -> ...);
// 5.0
builder.connectHandler(conn -> ...);The Pool#connectionProvider method has been deprecated and is replaced by the Supplier<Future<SqlConnectOptions>> method.
// 4.x
pool.connectionProvider(ctx -> futureOfSqlConnection(ctx));
// 5.0
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/vert-x3/issues/issues/632
Before Vert.x 5, Vert.x Health Check depended on Vert.x Web and Vert.x Auth.
It now only defines the HealthChecks API and the Health Check route handler has been moved to Vert.x Web.
The route handler API is not modified, but changing imports is required.
// 4.x
import io.vertx.ext.healthchecks.HealthCheckHandler;
// 5.0
import io.vertx.ext.web.healthchecks.HealthCheckHandler;https://github.com/vert-x3/vertx-web/pull/2607
Vert.x core introduces a new API to implement expectation checks inspired from the Web Client response expectation feature.
The Vert.x HTTP Client comes with the same set of predefined expectations than the Web Client response expectations, more importantly HTTP client response expectations can be re-used with Web Client.
The response predicates which is very specific to the Web Client responses, HTTP response expectations leverages the new Future#expecting method combined with the HttpResponseExpectation implementation.
// 4.x
client
.get(8080, "myserver.mycompany.com", "/some-uri")
.expect(ResponsePredicate.SC_SUCCESS)
.send()
.onSuccess(res -> {
// ....
});
// 5.0
client
.get(8080, "myserver.mycompany.com", "/some-uri")
.send()
.expecting(HttpResponseExpectation.SC_SUCCESS)
.onSuccess(res -> {
// ....
});The Vert.x Web Client documentation has been updated with the new response expectation API.
https://github.com/vert-x3/vertx-web/pull/2455
Vert.x Web Validation was based on a deprecated JSON Schema API, which is not longer available in Vert.x 5.
// 4.x
ValidationHandlerBuilder.create(schemaParser)
// 5.0
SchemaRepository schemaRepo = SchemaRepository.create(new JsonSchemaOptions().setDraft(DRAFT7));
ValidationHandlerBuilder.create(schemaRepo);Important: To improve security, the new SchemaRepository is not automatically loading external references. In case your schema contains an external references you must provide and dereference them upfront.
JsonSchema externalSchema = JsonSchema.of(new JsonObject......);
schemaRepo.dereference("http://example.org/my_external_schema", externalSchema);https://github.com/eclipse-vertx/vertx-json-schema/issues/114
In Vert.x 5 we removed the deprecated JSON Schema APIs. Before you had for every Draft an own SchemaParser. Now you have a SchemaRepository and can set the Draft in the options.
// 4.x
JsonObject schemaJson = new JsonObject(...);
Schema schema = new Draft7SchemaParser(SchemaRouter.create(vertx, new SchemaRouterOptions())).parse(schemaJson , scope);
JsonObject jsonToValidate = new JsonObject(...);
schema.validateSync(jsonToValidate);
// 5.0
JsonObject schemaJson = new JsonObject(...);
SchemaRepository schemaRepo = SchemaRepository.create(new JsonSchemaOptions().setDraft(DRAFT7));
JsonObject jsonToValidate = new JsonObject(...);
OutputUnit result = schemaRepo.validator(JsonSchema.of(schemaJson)).validate(jsonToValidate);
if (result.getValid()) {
// Successful validation
}https://github.com/vert-x3/vertx-rx/pull/301
io.vertx.core.buffer.Buffer has historically been part of the API as an async generated type, annotated by @VertxGen. It it has always been wrapped/unwrapped with reactive stream based like generators.
In Vert.x 5 this type becomes a data object since it does not have asynchronous methods and actually wraps a byte array. As consequence reactive streams like generators will not need anymore to wrap/unwrap this type which avoids un-necessary allocation, as trade off for a breaking change.
// 4.x
io.vertx.reactivex.core.buffer.Buffer buffer = rxApi.getBuffer();
// 5.0
io.vertx.core.buffer.Buffer buffer = rxApi.getBuffer();or
// 4.x
rxApi.setBuffer(io.vertx.reactivex.core.buffer.Buffer.buffer("the-string"));
// 5.0
rxApi.setBuffer(io.vertx.core.buffer.Buffer.buffer("the-string"));This version includes many security fixes since Hazelcast 4.2.8.
It requires JDK 11 to run, which is now the minimum required version in Vert.x 5.
// 4.x
stream.collecting(collector);
// 5.0
stream.collect(collector);TODO.
Micrometer 1.13 is a breaking change release if you are using the PrometheusMeterRegistry API in your code.
Please take a look at (Micrometer's migration guide)[https://github.com/micrometer-metrics/micrometer/wiki/1.13-Migration-Guide].