-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Migration Guide 3.13
Note
|
We highly recommend the use of Items marked below with ⚙️ ✅ are automatically handled by |
The JsonCommands.jsonMget()
method (and similar methods like ReactiveJsonCommands.jsonMget()
) declare parameters in the following order:
-
String path
-
K... keys
This is opposite to the Redis JSON.MGET command, which accepts keys first and path last.
The implementation of the jsonMget()
method used to follow the Redis order, despite its own declaration.
That is, the path
had to be last, even though it should be first.
This is now fixed. All users of this method have to check and fix the call sites.
Many changes on this release, affecting documentation, Metrics support and breaking changes due to the new semantic conventions for HTTP.
Added with experimental status, please set quarkus.otel.metrics.enabled=true
to enable it at build time.
Now you can create OpenTelemetry Metrics by following the Metrics Guide.
There are no automatic OpenTelemetry metrics instrumentation in Quarkus, for now. Metrics in Quarkus are implemented by the Micrometer extension. We plan to provide, in the future, a bridge for those metrics to be available in OpenTelemetry as well.
The old OpenTelemetry guide has been split into this generic guide, the OpenTelemetry Tracing Guide and the new OpenTelemetry Metrics Guide has been created.
-
Upgrade to OpenTelemetry SDK 1.39.0 and OpenTelemetry instrumentation 2.5.0. We haven’t upgraded OpenTelemetry for a while to allow a transition period from the old, deprecated HTTP semantic conventions, as announced in this wiki migration guide for Quarkus 3.9 and the Dev mailing list. The transition period has now ended with the upgrade of the OpenTelemetry SDK to 1.39.0 and OpenTelemetry instrumentation to 2.5.0. These versions require the new semantic conventions for HTTP. The full list of changes.
-
quarkus.otel.semconv-stability.opt-in
system property was removed because users cannot opt-in anymore; -
DB Span names have changed in the case of table creation;
-
Deprecated annotation for
io.opentelemetry.extension.annotations.WithSpan
has been removed. Please use the newio.opentelemetry.instrumentation.annotations.WithSpan
, as previously announced.
The extension now detects which extensions (Otel, Micrometer OTLP registry) are being used and sets their properties accordingly.
No need to configure the application.properties
file for this anymore. The documentation was also updated.
Breaking Change
The following properties are removed because they are not needed anymore:
-
quarkus.otel-collector.url
-
quarkus.grafana.url
Starting with Quarkus 3.13, before executing a JPQL/HQL or native query, Hibernate ORM will only flush pending changes to the database if it detects that the query results may be impacted by these changes.
This optimization was available for a long time in Hibernate ORM, but was disabled by mistake in Quarkus 1.13, causing performance issues ever since.
Most applications should only experience performance improvements (better batching), but some might run into problems:
-
if using native queries, which require specific care; see this section of the Hibernate ORM documentation.
-
if Hibernate ORM somehow fails to automatically detect that pending changes impact a JPQL/HQL query; please report any such problem with a reproducer based on this template.
-
Note auto-flush doesn’t currently flush query parameters — see https://hibernate.atlassian.net/browse/HHH-18563 .
-
While we initially planned replacing @QuarkusTestResource
with @WithTestResource
, some severe issues led us to reconsider this plan.
Thus, while you will see that @QuarkusTestResource
has been deprecated in 3.13, we will undeprecate it in 3.14 so please keep using it and don’t move to @WithTestResource
.
You can have a look at https://groups.google.com/g/quarkus-dev/c/rS8-WN6b7XQ for more details.
The default behaviour of calling quarkus config
is to display the help text for all subcommands instead of calling set
.
-
The Options
name
andvalue
are now Parameters. For instance, to set the configurationfoo=bar
, the previous command wasquarkus config set --name=foo --value=bar
. The new command isquarkus config set foo bar
. -
No longer removes the configuration if it exists from
application.properties
when thevalue
parameter is omitted from the command. Now, there is a specific subcommand to remove configurationquarkus config remove NAME
The way we check if Dev Services should be started has changed. We used to check if a property was defined to know if we should start the Dev Services or not without expanding it but it was causing issues if in the end the property was empty when expanded. We now check that the expanded property is empty, which might lead to the Dev Services being started while they weren’t in some cases.
For instance, people using the quarkus-test-oidc-server
component to mock the OIDC server will have to adjust their configuration due to a change in how we check the presence of configuration property in the Dev Services startup code.
Note that this particular example that is quite common is handled by quarkus update
⚙️ ✅.
If you have this in your application.properties
:
%test.quarkus.oidc.auth-server-url=${keycloak.url}/realms/quarkus/
You should change it to this:
%test.quarkus.oidc.auth-server-url=${keycloak.url:replaced-by-test-resource}/realms/quarkus/