Migration Guide 3.21

Table of Contents

• TLS Registry
• Quarkus REST
  • JsonView Deserialization changes

Note	We highly recommend the use of quarkus update to update to a new version of Quarkus. Items marked below with ⚙️ ✅ are automatically handled by quarkus update.

TLS Registry

The TLS registry extension has been reorganized to follow the structure proposed in https://github.com/quarkusio/quarkus/discussions/43130 and avoid split packages. Thus, the io.quarkus.tls.TlsRegistryBuildItem class has been renamed to io.quarkus.tls.deployment.spi.TlsRegistryBuildItem.

Quarkus REST

JsonView Deserialization changes

With this version, the deserialization support for jsonviews gets documented and slightly changed.

For example:

(1)

@POST
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
@JsonView(Views.Private.class)
public RestResponse<User> create(User user) {
    return RestResponse.status(CREATED, user);
}

(2)
@POST
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
@JsonView(Views.Private.class)
public RestResponse<User> create(@JsonView(Views.Public.class) User user) {
    return RestResponse.status(CREATED, user);
}

(1) The method parameter user was also deserialized using the Views.Private view. (2) The method parameter user was most likely to correctly use the expected Views.Public view for deserialization. For Serialization however, the Views.Public was also used, although the method is annoted with the Views.Private view.

The behaviour changed, so that now the deserialization is only influenced by the method parameter jsonview. The serialization is now always only influenced by the method (or class level) jsonview. For (1), the user parameter does not use any JsonView anymore. For (2), this means that the user parameter correctly uses Views.Public for deserialization, and for serialization Views.Private gets used