Skip to content

4.2.0 Deprecations and breaking changes

Jump to bottom
Paulo Lopes edited this page Oct 27, 2021 · 10 revisions

Vert.x Core

Random server port sharing within a verticle

Two distinct HTTP servers bound with port 0 yield the same random port within the instances of a same verticle deployment. This prevents a verticle to bind two HTTP servers with different random ports in the same verticle.

We decided to revert back to the previous behavior (two HTTP servers bounds with port 0 will have each a random port) and use negative port numbers to implement the previous behavior. Now this behavior is independant of a verticle, so multiple HTTP servers bounds with port -1 will share the same random port, same for -2, and so on.

Composite future create methods declare wildcard futures instead of raw futures

Until Vert.x 4.2 CompositeFuture declares raw future types in its create methods.

// Before 4.2.0
static CompositeFuture all(List<Future> futures) { ... }

// Since 4.2.0
static CompositeFuture all(List<Future<?>> futures) { ... }

Users should change their eventual List<Future> to List<Future<?>>, e.g

List<Future<?>> futures = Arrays.asList(f1, f2, f3, ...);

https://github.com/eclipse-vertx/vert.x/pull/4098/files

Context storage and retrieval of instances of any type

The API is not binary backward compatible but is compile time compatible.

https://github.com/eclipse-vertx/vert.x/pull/4068

HTTP Server Cookie changes

The HttpServerRequest/HttpServerResponse interfaces have deprecated the method:

Map<String, Cookie> cookieMap()

The implementation made a wrong assumption that cookies could be identified only by their name. The RFC however, states that the tuple of <name, domain, path> is the unique identifier.

When more than one cookie has the same name, the map will hold that lost one to be parsed and any previously parsed value will be silently overwritten.

A new method was added to allow getting all the cookies:

Set<Cookie> cookies()

Hazelcast cluster manager

Upgrade to Hazelcast 4.2

This version includes security fixes since Hazelcast 4.0.

Also, it removes an important limitation of AsyncMap when storing a value with TTL (rounded to the nearest second in Hazelcast 4.0).

Vert.x Web GraphQL

Context management with GraphQLContext object

With GraphQL-Java 17, the GraphQLContext object becomes the standard for sharing contextual data between components of a GraphQL Java application (see v17.0 release notes and https://github.com/graphql-java/graphql-java/pull/2368).

Vert.x 4.2 deprecates the existing hooks in Vert.x Web GraphQL handlers and introduces a new mechanism to configure the GraphQL execution.

Configuring a data loader before Vert.x 4.2:

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

Starting with Vert.x 4.2:

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);
});
Clone this wiki locally