Eclipse Vert.x 4 milestone 5 released!

We are ex­tremely pleased to an­nounce the fifth 4.0 mile­stone re­lease of Eclipse Vert.x.

Vert.x 4 is the evo­lu­tion of the Vert.x 3.x se­ries that will bring key fea­tures to Vert.x.

This re­lease aims to pro­vide a re­li­able dis­tri­b­u­tion of the cur­rent de­vel­op­ment of Vert.x 4 for peo­ple that want to try it and pro­vide feed­back.

New kids on the block: Json Schema, Web Validation and Web OpenAPI

we de­cide to take HTTP re­quest val­i­da­tion in vertx-web and Con­tract Dri­ven de­vel­op­ment using Ope­nAPI to a next level in Vert.x 4, allow us to in­tro­duce:

• Vert.x Json Schema: Ex­ten­si­ble sync/async json-​schema val­ida­tor de­signed for Vert.x JSON types, sup­port­ing Json Schema Draft-​7 and Ope­nAPI di­alect.
• Vert.x Web Val­i­da­tion: Ex­ten­si­ble sync/async HTTP re­quest val­ida­tor, pro­vid­ing a DSL to de­scribe ex­pected HTTP re­quests.
• Vert.x Web Ope­nAPI: New sup­port for Con­tract Dri­ven de­vel­op­ment based on Ope­nAPI

Vert.x Json Schema is a pow­er­ful Json Schema val­ida­tor which in­cludes:

• Async $ref res­o­lu­tion
• Cus­tom key­words/Cus­tom di­alects sup­port
• A DSL to build schemas

Com­bin­ing Vert.x Json Schema and Vert.x Web Val­i­da­tion you can eas­ily val­i­date HTTP re­quests:

ValidationHandler handler = ValidationHandler
  .builder(schemaParser)
  .pathParameter(Parameters.param("myPathParam", stringSchema()))
  .queryParameter(Parameters.optionalParam("myQueryParam", intSchema()))
  .body(Bodies.json(Schemas.ref(JsonPointer.fromURI(URI.create(
    "some_schema.json"
  )))))
  .build();

router.post("/{myPathParam}").handler(handler);

Check out the Web val­i­da­tion ex­am­ples and pro­vide feed­back on the APIs!

Vert.x Web Val­i­da­tion al­lows you to use Vert.x Web API Ser­vice with­out Vert.x Web API Con­tract: Vert.x Web API Ser­vice ex­am­ple

You can achieve Con­tract Dri­ven de­vel­op­ment, with Vert.x Web Ope­nAPI:

RouterFactory.create(vertx, "src/main/resources/petstore.yaml",
  routerFactoryAsyncResult -> {
  if (routerFactoryAsyncResult.succeeded()) {
    // Spec loaded with success, retrieve the router
    RouterFactory routerFactory = routerFactoryAsyncResult.result();
    // You can enable or disable different features of router factory using RouterFactoryOptions
    RouterFactoryOptions options = new RouterFactoryOptions();
    // Set the options
    routerFactory.setOptions(options);
    // Add an handler to operation listPets
    routerFactory.operation("listPets").handler(routingContext -> {
      // Handle listPets operation
      routingContext.response().setStatusMessage("Called listPets").end();
    }).failureHandler(routingContext -> { // Add a failure handler to the same operation
      // This is the failure handler
      Throwable failure = routingContext.failure();
      if (failure instanceof BadRequestException)
        // Handle Validation Exception
        routingContext
          .response()
          .setStatusCode(400)
          .putHeader("content-type", "application/json")
          .end(((BadRequestException)failure).toJson().toBuffer());
    });

    // Add a security handler
    // Handle security here
    routerFactory.securityHandler(
      "api_key",
      JWTAuthHandler.create(jwtAuth)
    );

    // Now you have to generate the router
    Router router = routerFactory.createRouter();
  } else {
    // Something went wrong during router factory initialization
  }
});

Vert.x Web Ope­nAPI is the new way to do Vert.x Web API Con­tract, how­ever Vert.x Web API Con­tract re­mains sup­ported for the whole life­time of Vert.x 4 to pro­vide a mi­gra­tion path: we will pro­vide soon a mi­gra­tion guide for Vert.x Web API Con­tract.

Check out the Web Ope­nAPI ex­am­ples

SQL Client templates

SQL Client Tem­plates is a small li­brary de­signed to fa­cil­i­tate the ex­e­cu­tion of SQL queries.

Sim­ply put you ex­e­cute pre­pared SQL queries with a map in­stead of a tuple:

Map<String, Object> parameters = Collections.singletonMap("id", 1);

SqlTemplate
  .forQuery(client, "SELECT * FROM users WHERE id=#{id}")
  .execute(parameters)
  .onSuccess(users -> {
    users.forEach(row -> {
      System.out.println(row.getString("first_name") + " " + row.getString("last_name"));
    });
  });

A tem­plate can per­form tuple to ob­ject map­ping for pa­ra­me­ters and rows.

Here is row map­ping using Jack­son Data­bind.

SqlTemplate
  .forQuery(client, "SELECT * FROM users WHERE id=#{id}")
  .mapTo(User.class)
  .execute(Collections.singletonMap("id", 1))
  .onSuccess(users -> {
    users.forEach(user -> {
      System.out.println(user.firstName + " " + user.lastName);
    });
  });

You can also uses Vert.x data ob­jects to gen­er­ate map­pers in­stead: when a data ob­ject is an­no­tate with @RowMapped a row map­per func­tion will be gen­er­ated

@DataObject
@RowMapped
class User {
  ...
}

// Generated by SQL template code generator
class UserRowMapper implements java.util.function.Function<io.vertx.sqlclient.Row, User> {
  ...
}

You can then use this map­per in­stead of User.class

SqlTemplate
  .forQuery(client, "SELECT * FROM users WHERE id=#{id}")
  .mapTo(UserRowMapper.INSTANCE)
  .execute(Collections.singletonMap("id", 1))
  .onSuccess(users -> {
    users.forEach(user -> {
      System.out.println(user.firstName + " " + user.lastName);
    });
  });

A new clustering SPI

This mile­stone in­tro­duces the clus­ter­ing SPI re­design that al­lows to:

• sim­plify both Vert.x core and clus­ter man­ager im­ple­men­ta­tions
• lever­age ca­pa­bil­i­ties of some clus­ter man­agers (e.g. data loss pro­tec­tion)

Read the RFC doc­u­ment if you would like to know more.

As a de­vel­oper, you should not see much dif­fer­ence, the Event­Bus and Shared data API re­main un­changed.

How­ever, if you op­er­ate a clus­ter in pro­duc­tion, you can­not mix Vert.x 3 and Vert.x 4 nodes.

The fol­low­ing clus­ter man­agers im­ple­men­ta­tions have been up­dated: vertx-hazelcast, vertx-infinispan and vertx-iginite (thanks Lukas Pret­ten­thaler for your help). The vertx-zookeeper up­date will be avail­able in the next re­lease.

Upgrade to Infinispan 10 and Ignite 2.8.0

Following-​up on the clus­ter­ing SPI up­date :

• the In­fin­is­pan clus­ter man­ager now de­pends on In­fin­is­pan 10
• the Apache Ig­nite clus­ter man­ager on 2.8.0

Complete refactoring on vertx-auth authn/authz split

Au­then­ti­ca­tion has been de­cou­pled from au­tho­riza­tion, all mod­ules now im­ple­ment at least one of the two in­ter­faces:

• AuthenticationProvider
• AuthorizationProvider

This im­prove­ment pro­vides more flex­i­b­lity such as user au­then­ti­ca­tion using a prop­erty file and au­tho­riza­tion against a data­base.

This mile­stone also in­cludes a few new im­ple­men­ta­tions:

• vertx-auth-ldap su­per­sedes shiro
• vertx-authproperties su­per­sedes shiro
• vertx-auth-sql to use sql-clients as source of user data
• vertx-auth-webauthn pro­vides FIDO2 webauthn au­then­ti­ca­tion

Many bug fixes have been done and miss­ing fea­tures such as JWK ro­ta­tion sup­port for OAuth2/OIDC/JWT is now im­ple­mented.

Vertx-web updates

Vert.x-Web also got some up­dates.

The ses­sion han­dler code now al­lows other stor­ages:

• cookie-session-store - stores all ses­sion data in a cookie
• redis-session-store - store all ses­sion data in a redis key store data­base

Ses­sions fol­lows the lat­est OWASP rec­om­men­da­tions and al­lows to now use cookieless ses­sions, where the ses­sion key is passed in the URL.

Routers are now proxy aware: when en­abled, routers can parse the Forward head­ers and re­bind the in­ter­nal val­ues for pro­to­col, host and port for user con­vinience. This is quite use­ful when ap­pli­ca­tions are de­ployed be­hind a caching server, which can mod­ify the orig­i­nal re­quest.

JUnit 5 support updates

The vertx-junit5 mod­ule has had the fol­low­ing up­dates since the last mile­stone.

• The in­ter­nals have been refac­tored to split the im­ple­men­ta­tion and ex­ten­sions around a service-​provider in­ter­face. While this is largely trans­par­ent in terms of API, you need to be aware that:
  • the Vertx pa­ra­me­ter should be placed be­fore any pa­ra­me­ter that re­quires it for cre­ation, such as when in­ject­ing a We­b­Client,
  • the vertx-​junit5 mod­ule now only of­fers APIs for the Vert.x core mod­ule (vertx-​core),
  • the reactiverse-​junit5-​extensions mod­ule now hosts ex­ten­sions that offer extra pa­ra­me­ter types like We­b­Client,
  • the Rx­Java 1 and 2 bind­ings are now of­fered as vertx-​junit5-​rx-java and vertx-​junit5-​rx-java2 mod­ules in the vertx-​junit5-​extensions repos­i­tory.
• The succeeding() and failing() meth­ods in VertxTestContext have been dep­re­cated to im­prove er­gonom­ics, you should in­stead use succeedingThenComplete() and failingThenComplete().

Ramping up to Vert.x 4

In­stead of de­vel­op­ing all new fea­tures ex­clu­sively in Vert.x 4, we in­tro­duce some of these fea­tures in the 3.x branch so the com­mu­nity can ben­e­fit from them. The Vert.x 4 de­vel­op­ment focus on more fun­da­men­tal changes that can­not be done in the 3.x se­ries.

This is the fifth mile­stone of Vert.x 4, you can of course ex­pect more mile­stones to out­line the progress of the ef­fort.

You can also read the pre­vi­ous mile­stone an­nounces:

• https://vertx.io/blog/eclipse-​vert-x-4-​milestone-4-​released
• https://vertx.io/blog/eclipse-​vert-x-4-​milestone-3-​released
• https://vertx.io/blog/eclipse-​vert-x-4-​milestone-2-​released
• https://vertx.io/blog/eclipse-​vert-x-4-​milestone-1-​released

Finally

The dep­re­ca­tions and break­ing changes can be found on the wiki.

The re­lease ar­ti­facts have been de­ployed to Maven Cen­tral and you can get the dis­tri­b­u­tion on Maven Cen­tral.

You can boot­strap a Vert.x 4.0.0-​milestone5 project using https://start.vertx.io.

The doc­u­men­ta­tion has been de­ployed on this pre­view web-​site https://vertx-​ci.github.io/vertx-​4-​preview/docs/

That’s it! Happy cod­ing and see you soon on our user or dev chan­nels.