Migration Guide 2.14

Kubernetes Client upgraded to 6.1

The Kubernetes Client has been upgraded from 5.12 to 6.1. Please refer to the Kubernetes Client 6 migration guide.

@ConfigProperties was removed

The deprecated annotation io.quarkus.arc.config.ConfigProperties was removed. Users are encouraged to use the @io.smallrye.config.ConfigMapping instead. Please read the Mapping configuration to objects for more information.

OpenTelemetry exporters moved

The quarkus-opentelemetry-exporter-jaeger extension was moved to the quarkus-opentelemetry-exporter at Quarkiverse. The quarkus-opentelemetry-exporter-otlp extension was removed and the code is now part of quarkus-opentelemetry, as the default exporter. Your project dependencies need to be updated accordingly. The config properties remain the same.

RESTEasy Reactive multipart changes

The following changes impact multipart support in RESTEasy Reactive:

• BREAKING: Previously, you could catch all file uploads regardless of the parameter name using the syntax: @RestForm List<FileUpload> all, but this was ambiguous and unintuitive, so now this form will only fetch parameters named all (just like for every other form element of other types) and you have to use this form to catch every parameter regardless of its name: @RestForm(FileUpload.ALL) List<FileUpload> all.
• The @MultipartForm annotation is now deprecated. It is now equivalent to @BeanParam which you may use in its stead. Multipart form parameter support has been added to @BeanParam
• The @BeanParam is now optional and implicit for any non-annotated method parameter which has fields annotated with any @Rest* or @*Param annotations.
• Multipart elements are no longer limited to being encapsulated inside @MultipartForm-annotated classes: they can be used as method endpoint parameters as well as endpoint class fields.
• Multipart elements now default to the @PartType(MediaType.TEXT_PLAIN) mime type, unless they are of type FileUpload, Path, File, byte[] or InputStream
• Multipart elements of the MediaType.TEXT_PLAIN mime type are now deserialised using the regular ParamConverter infrastructure (previously they were using MessageBodyReader)
• Multipart elements of the FileUpload, Path, File, byte[] or InputStream types are deserialised specially.
• Multipart elements of other mime types (explicitely set) still use the appropriate MessageBodyReader infrastructure.
• Multipart elements can now be wrapped in List in order to obtain all values of the part that have the same name.
• Any client call including @RestForm or @FormParam parameters defaults to the MediaType.APPLICATION_FORM_URLENCODED content type, unless they are of the File, Path, Buffer, Multi<Byte> or byte[] types, in which case it defaults to the MediaType.MULTIPART_FORM_DATA content type.