Skip to content

Migration Guide 2.1

Jump to bottom
Ladislav Thon edited this page Jul 22, 2021 · 16 revisions

Hibernate with Panache split packages

To avoid split packages:

  • ProjectedFieldName has been moved from io.quarkus.hibernate.orm.panache to io.quarkus.hibernate.orm.panache.common.

The original, now deprecated, classes haven been kept in 2.1 and will be removed in 2.2.

MongoDB with Panache split packages

To avoid split packages:

  • MongoEntity has been moved from io.quarkus.mongodb.panache to io.quarkus.mongodb.panache.common.
  • ProjectionFor has been moved from io.quarkus.mongodb.panache to io.quarkus.mongodb.panache.common.
  • PanacheUpdate has been moved from io.quarkus.mongodb.panache to io.quarkus.mongodb.panache.common.
  • ReactivePanacheUpdate has been moved from io.quarkus.mongodb.panache.reactive to io.quarkus.mongodb.panache.common.reactive.

The original, now deprecated, classes haven been kept in 2.1 and will be removed in 2.2.

Config

The @WithName annotation for @ConfigMapping now correctly used the name as is to map the configuration name and not a transformed version. Example:

@ConfigMapping
interface Server {
 @WithName("theHost")
 String server();
}

In Quarkus 2.x, the theHost name would map to the the-host configuration. Starting with Quarkus 2.1 it now maps with the exact name of theHost.

OpenShift

Java command and arguments mapping

When deploying a Quarkus application into OpenShift, by default the container configuration to run the application looked like:

command: java
args:
    - '-Dquarkus.http.host=0.0.0.0'
    - '-Djava.util.logging.manager=org.jboss.logmanager.LogManager'
    - '-jar'
    - /deployments/quarkus-run.jar

Both command and args fields can be overriden via the quarkus.openshift.command and quarkus.openshift.arguments properties.

However, users can't simple append their custom Java arguments, for example: java -jar /deployments/quarkus-run.jar param1 param2. The only workaround was to copy and paste the existing content in the default args field and append the custom arguments param1 and param2.

This has been fixed in 2.0 by moving all the Java related parameters into the command field:

command: 
    - 'java'
    - '-Dquarkus.http.host=0.0.0.0'
    - '-Djava.util.logging.manager=org.jboss.logmanager.LogManager'
    - '-jar'
    - /deployments/quarkus-run.jar

Now, users can use the quarkus.openshift.arguments property to append their custom Java arguments, for example: quarkus.openshift.arguments=param1,param2.

SmallRye Fault Tolerance

Quarkus 2.1 updates SmallRye Fault Tolerance to version 5.2, which introduces a special mode, not compatible with the MicroProfile Fault Tolerance specification. In this mode, methods with fault tolerance annotations are automatically treated as asynchronous if they have an asynchronous return type (CompletionStage or Uni), even if they don't have any asynchronous annotation (@Asynchronous, @Blocking, @NonBlocking). If an annotation is present, it is of course still honored.

Quarkus enables this non-compatible mode by default. If you need strict compatibility with MicroProfile Fault Tolerance, you can set smallrye.faulttolerance.mp-compatibility=true. For more information, see https://smallrye.io/docs/smallrye-fault-tolerance/5.2.1/usage/extra.html#_non_compatible_mode

Clone this wiki locally