-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Migration Guide 3.21
Note
|
We highly recommend the use of Items marked below with ⚙️ ✅ are automatically handled by |
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
.
With this version, the deserialization support for JSON views gets documented and slightly changed.
For example:
@POST
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
@JsonView(Views.Private.class)
public RestResponse<User> create(User user) { (1)
return RestResponse.status(CREATED, user);
}
@POST
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
@JsonView(Views.Private.class) (2)
public RestResponse<User> create(@JsonView(Views.Public.class) User user) {
return RestResponse.status(CREATED, user);
}
-
The method parameter
user
was also deserialized using theViews.Private
view. -
The method parameter
user
was most likely to correctly use the expectedViews.Public
view for deserialization. For Serialization however, theViews.Public
was also used, although the method is annoted with theViews.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 JSON view anymore. -
For (2), this means that the
user
parameter correctly usesViews.Public
for deserialization, and for serializationViews.Private
gets used