-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Migration Guide 2.1
To avoid split packages:
-
ProjectedFieldName
has been moved fromio.quarkus.hibernate.orm.panache
toio.quarkus.hibernate.orm.panache.common
.
The original, now deprecated, classes haven been kept in 2.1 and will be removed in 2.2.
To avoid split packages:
-
MongoEntity
has been moved fromio.quarkus.mongodb.panache
toio.quarkus.mongodb.panache.common
. -
ProjectionFor
has been moved fromio.quarkus.mongodb.panache
toio.quarkus.mongodb.panache.common
. -
PanacheUpdate
has been moved fromio.quarkus.mongodb.panache
toio.quarkus.mongodb.panache.common
. -
ReactivePanacheUpdate
has been moved fromio.quarkus.mongodb.panache.reactive
toio.quarkus.mongodb.panache.common.reactive
.
The original, now deprecated, classes haven been kept in 2.1 and will be removed in 2.2.
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
.
Hibernate Reactive needs to run on the Vert.x eventloop. Running it on other threads has never been supported and would likely lead to subtle to identify problems caused by unintended concurrency, but it wasn't checked.
Since Quarkus 2.1 there is an active guard protecting users from this mistake, so you'll see a runtime exception if you attemp to use it from the wrong thread.
We strongly recommend trying to design Reactive applications to stick to the pure event loop as that is the most efficient and best performing solution for a reactive app. If this doesn't apply to you, please consider using the classic version of Hibernate ORM which is more suited for applications which are not running on the eventloop.
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
.
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 non-blocking 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
In the Quarkus 2.1.0.Final release the io.quarkus:quarkus-universe-bom
typically imported by Quarkus applications is deprecated in favor of the Quarkus platform member-specific BOMs:
- io.quarkus.platform:quarkus-bom:2.1.0.Final
- io.quarkus.platform:quarkus-optaplanner-bom:2.1.0.Final
- io.quarkus.platform:quarkus-kogito-bom:2.1.0.Final
- io.quarkus.platform:quarkus-qpid-jms-bom:2.1.0.Final
- io.quarkus.platform:quarkus-cassandra-bom:2.1.0.Final
- io.quarkus.platform:quarkus-camel-bom:2.1.0.Final
- io.quarkus.platform:quarkus-hazelcast-client:2.1.0.Final
- io.quarkus.platform:quarkus-debezium-bom:2.1.0.Final
- io.quarkus.platform:quarkus-blaze-persistence-bom:2.1.0.Final
- io.quarkus.platform:quarkus-google-cloud-services-bom:2.1.0.Final
The platform member-specific BOMs above are actually fragments of the legacy io.quarkus:quarkus-universe-bom
and so it doesn't matter in which order they are imported in applications. The main advantage is that instead of enforcing all the dependency version constraints from the Quarkus "universe" BOM, applications may import only those constraints that are actually relevant to them. You can read more about this change in the blog post introducing this change.
NOTE: that the Quarkus dev tools, including code.quarkus.io, will now be generating projects importing the BOMs that are relevant to the extensions selected for the project to be created.
The io.quarkus:quarkus-universe-bom
is still going to be released in the upcoming versions of the Quarkus platform in addition to the member-specific BOMs to give time for the existing applications to migrate to the new BOMs.