-
Notifications
You must be signed in to change notification settings - Fork 3.2k
Migration Guide 3.36
|
Note
|
We highly recommend the use of Items marked below with ⚙️ ✅ are automatically handled by |
The API has been updated to use the Jakarta Data Order type instead of the Panache Sort type.
Please note that this will be the case for the Page type too in the near future.
The quarkus.otel.exporter.otlp.memory-mode property configures the memory allocation strategy for OTLP exporters.
The default value immutable-data creates new serialization objects for each export.
Setting it to reusable-data enables object pooling to reduce garbage collection pressure, which can be beneficial in memory-constrained environments.
When running the application in Kubernetes, the OpenTelemetry Kubernetes resource attributes can be populated manually or by using the quarkus-kubernetes extension.
LateBoundSpanProcessor and RemoveableLateBoundSpanProcessor have been deprecated and marked for removal.
If you rely on the behavior of those classes, please checkout the new proposed code and prepare accordingly. The SpanProcessorCustomizer should be used in the future. See: https://github.com/quarkusio/quarkus/pull/52752
The following classes have been moved from the io.quarkus.tls.runtime package (in the quarkus-tls-registry runtime module) to the io.quarkus.tls package (in the quarkus-tls-registry-spi module):
| Old class (3.35) | New class (3.36) |
|---|---|
|
|
|
|
|
|
|
|
If your code implements KeyStoreProvider or TrustStoreProvider, update the import statements:
// Before
import io.quarkus.tls.runtime.KeyStoreProvider;
import io.quarkus.tls.runtime.KeyStoreAndKeyCertOptions;
import io.quarkus.tls.runtime.TrustStoreProvider;
import io.quarkus.tls.runtime.TrustStoreAndTrustOptions;
// After
import io.quarkus.tls.KeyStoreProvider;
import io.quarkus.tls.KeyStoreAndKeyCertOptions;
import io.quarkus.tls.TrustStoreProvider;
import io.quarkus.tls.TrustStoreAndTrustOptions;The old classes no longer exist — this is a compile-breaking change.
The TLS Registry now supports arbitrary keystore and truststore types (e.g., BCFKS) via a new other configuration group, without requiring custom code for standard types. Configure it with:
quarkus.tls.key-store.other.type=BCFKS
quarkus.tls.key-store.other.provider=BCFIPS
quarkus.tls.key-store.other.path=server-keystore.bcfks
quarkus.tls.key-store.other.password=secretFor types that require custom loading logic, implement a KeyStoreFactory or TrustStoreFactory CDI bean annotated with @Identifier that matches the type value. See the [TLS Registry reference](https://quarkus.io/guides/tls-registry-reference) for details.
GraphQL clients that use the TLS registry will now dynamically reload its TLS configuration immediately when the respective TLS registry configuration is updated (for example, with a new certificate). Previously, a single instance of GraphQL client kept its TLS configuration unchanged and so the changes affected only newly created instances, so they had to have a short CDI scope. Now, the change will be applied immediately independent of the GraphQL client’s CDI scope.