Quarkus 0.24.0 released - Vert.x everywhere

This means that if your application depends on quarkus-resteasy and not quarkus-undertow then Servlet will not be present, and RESTEasy will run directly on a Vert.x backend.

For most applications this should be largely transparent, however if you wish to use Servlet filters or other Servlet functionality then you can simply add a dependency on quarkus-undertow. If Undertow is present, RESTEasy will detect this and will fall back to running as a Servlet.

Please reach out to us if you think a missing feature should be supported out of the box by RESTEasy + Vert.x because we want as many users as possible on the new Vert.x layer.

For instance, we introduced quarkus.http.root-path as the counterpart of quarkus.servlet.context-path.

Previously Security was tied to Undertow and only applied to Servlet deployments, while also being 100% blocking. This change brings in a new security layer that is not tied to any specific implementation, and also allows for reactive security operations to integrate with Vert.x. It is also no longer tied to Elytron, however Elytron still remains an option.

This is still a work in progress and there is a lot more work to come over the following few weeks, however the main changes today are:

The original Keycloak-specific quarkus-keycloak adapter has been replaced with a generic OpenID Connect (OIDC) quarkus-oidc adapter which will provide a comprehensive, generic and reactive support for the most important OIDC flows and be able to verify the tokens from all the certified OIDC providers including Keycloak. Tokens from the other OIDC and OAuth2 providers implementing a token introspection endpoint will also be recognized.

You can find all the information relative to this new extension in our new OIDC guide but here is a summary of the changes that will probably affect you.

Note that the configuration namespace has changed from quarkus.keycloak to quarkus.oidc. The realm property has been removed and the Keycloak users are now required to configure the auth-base-url as follows:

where {realm} represents a Keycloak realm.

resource has been renamed to client-id. realm-public-key has been renamed to public-key.

Multi-tenancy support based on KeycloakConfigResolver is no longer supported with a Vert.x OAuth2 based alternative mechanism to be introduced in the next release.

Users needing to configure CORS should now use Quarkus CORS filter.

The team appreciates that some of the original quarkus-keycloak users may be affected by this change and would like to assure the community that quarkus-oidc will offer an equivalent but also significantly better overall OIDC experience very soon.

If some features are missing for your use case, please open GitHub issues.

You might already have used our Hibernate ORM with Panache layer. This simplified "Panache" approach will be generalized to other parts of the stack in the coming months.

And we already have a good news: we now have a MongoDB with Panache extension which heavily simplifies developing REST applications with MongoDB. You can find all the information in the MongoDB with Panache guide, which comes with a quickstart.

As for every brand new feature, feedback is highly welcome.

It is now far easier to customize Jackson’s ObjectMapper or JSON-B configuration thanks to a new API we introduced in 0.24.

Everything is explained in detail in our REST JSON guide.

We now support named request handlers.

We updated REST Assured to 4.1.1: there is a good chance you will have to adjust your tests. Checkout the Rest Assured Release Notes for details.

We also fixed a few bugs and usability issues: get the full changelog of 0.24.0 on GitHub.