이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Migrating applications to Red Hat build of Quarkus 3.27


Red Hat build of Quarkus 3.27

Red Hat Customer Content Services

Abstract

This guide describes how to migrate applications from earlier versions of Red Hat build of Quarkus to the current version.

Chapter 1. Migrating applications to Red Hat build of Quarkus 3.27

As an application developer, you can migrate applications that are based on Red Hat build of Quarkus version 3.2 or later to version 3.27 by using either the quarkus CLI or Maven.

Important

The Quarkus CLI is intended for development purposes, including tasks such as creating, updating, and building Quarkus projects. However, Red Hat does not support using the Quarkus CLI in production environments.

1.1. Updating projects to the latest Red Hat build of Quarkus version

To update your Red Hat build of Quarkus projects to the latest version, follow these steps, which are explained in detail later in this guide:

  1. Use the quarkus CLI or Maven commands to run automated update tasks.
  2. Consult the Changes that affect compatibility with earlier versions section to perform any manual update tasks.

1.1.1. Automatic updates

Running the quarkus CLI or Maven commands triggers OpenRewrite recipes that upgrade project dependencies and source code. This automated approach provides a convenient and reliable way to update your projects.

However, not all migration tasks are automated. If specific updates are not applied after running the quarkus update command or its Maven equivalent, consider the following possible reasons:

  • The required migration task is not covered by the available OpenRewrite recipes.
  • An extension your project depends on is incompatible with the latest Red Hat build of Quarkus version.

1.1.2. Manual updates

Manual updates give you the flexibility and control to address any migration tasks to ensure your project aligns with your specific needs. Tasks that are not automated must be handled manually.

For a list of the migration tasks required to update from the previous release to this one, see the Changes That Affect Compatibility with Earlier Versions section of this guide.

Reviewing the migration guide for each release version between the current version of your application project and the version you’re upgrading to is essential. This review process ensures you are fully informed and prepared for the update process. For example, if upgrading from version 3.20 to 3.27, you only need to review this guide. If you are upgrading from version 3.2 to 3.27, you must also review the guides for for each intermediate version:

Each task in this migration guide outlines the required changes and indicates whether they are automatically handled by the quarkus update command and its Maven equivalent.

For additional background, see the Quarkus community Migration guides.

1.2. Using the quarkus CLI to update the project

Update your Red Hat build of Quarkus projects by using the quarkus CLI.

Important

The Quarkus CLI is intended for development purposes, including tasks such as creating, updating, and building Quarkus projects. However, Red Hat does not support using the Quarkus CLI in production environments.

Prerequisites

Procedure

  1. Create a working branch for your project in your version control system.
  2. Install the latest version of the quarkus CLI by following the installation guide.
  3. Verify the installation by running the following command:

    quarkus -v
    3.27.0
    Copy to Clipboard Toggle word wrap
  4. Important: Configure the extension registry client as instructed in the "Configuring Red Hat build of Quarkus extension registry client" section of the "Getting Started with Red Hat build of Quarkus" guide.
  5. In the terminal, navigate to your project directory.
  6. Update the project:

    quarkus update
    Copy to Clipboard Toggle word wrap

    Optional: To update to a specific stream, use the --stream option followed by a specific version; for example:

    quarkus update --stream=3.27
    Copy to Clipboard Toggle word wrap
  7. Review the output from the update command for instructions and perform any suggested tasks.
  8. Use a diff tool to inspect all changes made during the update process.
  9. Manually perform any changes that were not handled by updating the project. For details, refer to the following Changes that affect compatibility with earlier versions section.
  10. Ensure the project builds without errors, all tests pass, and the application functions as expected before deploying to production.

1.3. Using Maven to update the project

Update your Red Hat build of Quarkus projects by using Maven.

Prerequisites

Procedure

  1. Create a working branch for your project in your version control system.
  2. Important: Configure the extension registry client as detailed in the "Configuring Red Hat build of Quarkus extension registry client" section of the "Getting Started with Red Hat build of Quarkus" guide.
  3. Open a terminal and navigate to your project directory.
  4. Ensure that the Red Hat build of Quarkus Maven plugin version is aligned with the latest supported version. Configure the project according to the "Getting started with Red Hat build of Quarkus" guide, and then run:

    mvn com.redhat.quarkus.platform:quarkus-maven-plugin:3.27.0.redhat-00001:update
    Copy to Clipboard Toggle word wrap

    Optional: To update to a specific stream, use the -Dstream option followed by the desired version; for example:

    mvn com.redhat.quarkus.platform:quarkus-maven-plugin:3.27.0.redhat-00001:update -Dstream=3.27
    Copy to Clipboard Toggle word wrap
  5. Review the output from the update command for any instructions and perform the suggested tasks.
  6. Use a diff tool to examine all changes made during the update process.
  7. Manually perform any changes that were not handled by updating the project. For details, refer to the following Changes that affect compatibility with earlier versions section.
  8. Ensure the project builds without errors, all tests pass, and the application functions as expected before deploying to production.

1.4. Changes that affect compatibility with earlier versions

This section describes changes in Red Hat build of Quarkus 3.27 that affect the compatibility of applications built with earlier product versions.

Review these breaking changes and take the necessary steps to ensure that your applications continue functioning after updating them to Red Hat build of Quarkus 3.27.

You can perform many of the updates listed in this section by running quarkus update or the equivalent Maven command. This triggers automated OpenRewrite recipes that update your project dependencies and source code to the latest Red Hat build of Quarkus version.

However, not all migration tasks are automated. If specific updates aren’t applied by the automated update, it might be because the required migration task isn’t covered by the available OpenRewrite recipes or an extension your project relies on is incompatible with the latest version. In such cases, you need to perform the updates manually. Be sure to review the following items to identify and address any manual migration tasks.

1.4.1. Compatibility

1.4.1.1. Transactions: QuarkusTransaction.isActive() deprecated

In the current release, the QuarkusTransaction.isActive() method is deprecated.

The method’s behavior is ambiguous and does not reliably indicate transaction state.

Use the getStatus() method to determine the current transaction status. Update all existing uses of isActive() to getStatus() to ensure correct behavior.

To apply this change, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

For more information, see the Quarkus Migration guide 3.22.

1.4.2. Core

1.4.2.1. Configuration: Legacy config classes removed

In the current release, Quarkus removes support for legacy configuration classes. Applications that rely on extensions, including custom extensions, built on legacy configuration classes, fail to build.

Update affected extensions to versions that use @io.smallrye.config.ConfigMapping, or migrate custom extensions accordingly.

For example, replace the compatibility class GlobalDevServicesConfig with DevServicesConfig.

To apply this change, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

For more information, see the following resources:

1.4.2.2. Configuration: Use .enabled instead of .enable in configuration properties

In the current release, feature toggles in configuration use the .enabled suffix instead of .enable. This change enhances consistency across configuration properties and prevents the mixing of suffixes. The old .enable properties remain recognized for backward compatibility but are deprecated.

Run quarkus update to automatically migrate your configuration. If you update manually, rename keys such as quarkus.log.console.enable to quarkus.log.console.enabled to avoid deprecation warnings. Named logging handlers follow the same rule and use quarkus.log.handler.*."handler-name".enabled.

Example 1.1. Impacted properties include:

  • quarkus.keycloak.policy-enforcer.enablequarkus.keycloak.policy-enforcer.enabled
  • quarkus.log.console.enablequarkus.log.console.enabled
  • quarkus.log.console.async.enablequarkus.log.console.async.enabled
  • quarkus.log.file.enablequarkus.log.file.enabled
  • quarkus.log.file.async.enablequarkus.log.file.async.enabled
  • quarkus.log.syslog.enablequarkus.log.syslog.enabled
  • quarkus.log.syslog.async.enablequarkus.log.syslog.async.enabled
  • quarkus.log.socket.enablequarkus.log.socket.enabled
  • quarkus.log.socket.async.enablequarkus.log.socket.async.enabled
  • quarkus.snapstart.enablequarkus.snapstart.enabled
  • quarkus.smallrye-health.ui.enablequarkus.smallrye-health.ui.enabled
  • quarkus.smallrye-graphql.ui.enablequarkus.smallrye-graphql.ui.enabled
  • quarkus.smallrye-openapi.enablequarkus.smallrye-openapi.enabled
  • quarkus.swagger-ui.enablequarkus.swagger-ui.enabled

To apply this change, run the automatic update process described in the Migrating applications to Red Hat build of Quarkus 3.27 guide.

For more information, see the Quarkus Migration guide 3.26: `.enable` to `.enabled` in configuration properties.

1.4.2.3. JGit: Dependency removed from quarkus-bom

In the current release, the org.eclipse.jgit dependency is no longer managed in the quarkus-bom.

Now, if your application relies on JGit, add the quarkus-jgit extension to your dependencies to ensure native image compatibility and to use a compatible library version.

The quarkus-jgit extension is not supported in Red Hat build of Quarkus.

To apply this change, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

For more information, see the Quarkus Migration guide 3.22.

1.4.2.4. JSON-RPC: Extensions must always produce JsonRPCProvidersBuildItem

In the current release, a JsonRPCProvidersBuildItem must be produced regardless of the build mode.

Previously, most extensions produced this build item only in dev mode by using @BuildStep(onlyIf = IsDevelopment.class).

Now, the build process requires this item at build time to enable execution model validation on JSON-RPC classes.

The build process uses this item to identify JSON-RPC endpoints, particularly classes that use annotations such as @Blocking, @NonBlocking, or @RunOnVirtualThread.

  • To migrate, replace conditional build steps as follows:

    • Previously used code:

      @BuildStep(onlyIf = IsDevelopment.class)
      JsonRPCProvidersBuildItem createJsonRPCService() {
          return new JsonRPCProvidersBuildItem(...);
      }
      Copy to Clipboard Toggle word wrap
    • Updated code:

      @BuildStep
      JsonRPCProvidersBuildItem createJsonRPCService() {
          return new JsonRPCProvidersBuildItem(...);
      }
      Copy to Clipboard Toggle word wrap

Quarkus previously provided a fallback detection mechanism for JSON-RPC classes. That mechanism is removed in the current release.

To apply this change, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

For more information, see the Quarkus Migration guide 3.22: extensions must produce JsonRPCProvidersBuildItem always.

1.4.2.5. Stork: No longer managed by REST Client

In the current release, Stork is no longer a built-in dependency of the REST Client.

Now, you must add the quarkus-stork extension to your project dependencies to use Stork with REST Client.

To apply this change, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

For more information, see the Quarkus Migration guide 3.22.

1.4.2.6. Test native-image-profile configuration property removed

Breaking change: The current release removes the long-deprecated quarkus.test.native-image-profile configuration property. Update any configurations that still use the removed property to use the current quarkus.test.integration-test-profile property instead.

The quarkus.test.integration-test-profile property specifies the configuration profile to use when running tests with @QuarkusIntegrationTest:

  • Type: String
  • Default value: prod
  • Environment variable: QUARKUS_TEST_INTEGRATION_TEST_PROFILE
  • Configuration timing: Fixed at build time

To apply this change, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

1.4.3. Data

1.4.3.1. Apache Derby database support removed

In the current release, support for the Apache Derby database has been removed from Red Hat build of Quarkus.

Apache Derby was deprecated in a previous release and has now been fully removed. Applications using Derby should migrate to a supported database such as PostgreSQL, MySQL, MariaDB, or another database listed in the supported configurations.

If your application currently uses Derby, you will need to:

  • Update your application dependencies to remove Derby JDBC drivers
  • Update your application.properties or application.yaml to configure a different database
  • Migrate your existing Derby database schema and data to the new database

For information about configuring datasources in Red Hat build of Quarkus, see Configuring data sources.

To apply this change, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

1.4.3.2. Dev Services default images updates

In the current release, the default images for the following Dev Services have been updated to the following versions:

  • Elasticsearch version 9.1
  • OpenSearch version 3.1

Breaking change: If your applications require specific versions of these images, you must configure the container image explicitly. For example:

quarkus.elasticsearch.devservices.image-name=docker.io/elastic/elasticsearch:9.1.3
Copy to Clipboard Toggle word wrap

To apply this change, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

For more information, see the Configuring the image section of the Quarkus "Dev Services for Elasticsearch" guide.

1.4.3.3. Hibernate ORM: Database version checks

In the current release, Hibernate ORM improves database version checks.

Earlier releases already applied these checks; this update enhances version detection accuracy and expands the scope of checks run at startup.

If application startup fails the version check, set the correct database version for your dialect or upgrade the database to a supported version.

When you use CockroachDialect, set the CockroachDB version (not a PostgreSQL version) to match the server your application connects to.

To apply this change, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

For more information, see the Quarkus Migration guide 3.25.

1.4.3.4. Hibernate ORM: Schema management configuration properties renamed

In the current release, the following Hibernate ORM (quarkus-hibernate-orm) extension properties are renamed to simplify YAML configuration and prepare for future changes.

The old properties remain recognized in the current release, but are deprecated and are planned to be removed in a future release.

Use the new properties when you upgrade to the current release.

Expand
Old property nameNew property name

quarkus.hibernate-orm.database.generation

quarkus.hibernate-orm.schema-management.strategy

quarkus.hibernate-orm.database.generation.create-schemas

quarkus.hibernate-orm.schema-management.create-schemas

quarkus.hibernate-orm.database.generation.halt-on-error

quarkus.hibernate-orm.schema-management.halt-on-error

To apply this change, run the automatic update process described in the Migrating applications to Red Hat build of Quarkus 3.27 guide.

1.4.3.5. Hibernate ORM: Upgraded to version 7.1

In the current release, Hibernate ORM has been upgraded to version 7.1. This upgrade introduces breaking changes that might affect your applications.

  • API changes

    • Deprecated Session methods have been removed or replaced by JPA equivalents.

      To apply changes marked as "Automatic", run the automatic update process described in the Migrating applications to Red Hat build of Quarkus 3.27 guide, otherwise manually perform any additional steps.

      Expand
      Deprecated Session methodNew JPA equivalentUpdate process

      load(…​) without a lock option

      getReference(…​)

      Automatic

      get(…​)

      find(…​)

      Automatic

      delete(…​)

      remove(…​)

      Automatic

      save(…​)

      persist(…​)

      Automatic

      update(…​)

      merge(…​)

      Manual

      load(…​) with a lock option

      find(…​)

      Manual

      saveOrUpdate(…​)

      persist (new entity) / merge (persisted, then detached entity)

      Manual

      Note

      When migrating from an update method to a merge method, be aware of the following differences:

      • merge returns an entity instance attached to the persistence context. Ensure that you use that entity and discard the one passed as an argument.
      • To ensure proper merging, merge can load the entity. When using merge on multiple entities in succession, N+1 select issues might occur. To avoid this issue, load all entities in the session before the merge call, for example, by using Session#findMultiple.

      To apply this change, manually perform any additional steps described in this release note.

      For more information, see Hibernate ORM Defer to JPA.

    • Deprecated annotations have been removed or replaced by JPA equivalents. To view the impacted annotations, see Hibernate ORM Annotations.
    • @Cascade and CascadeType are deprecated and replaced by JPA equivalents such as @OneToMany(cascade = …​).

      To apply this change, run the automatic update process described in the Migrating applications to Red Hat build of Quarkus 3.27 guide.

    • Proxy customization has changed. If you were using @Proxy, consider @ConcreteProxy instead, or use the Session#getReference or Hibernate#unproxy methods. For more information, see Hibernate ORM Replace @Proxy.
    • org.hibernate.Metamodel was removed and replaced by org.hibernate.metamodel.model.domain.JpaMetamodel.
    • The UserType and CompositeType method signatures changed to no longer refer to internal or Service Provider Interface (SPI) types. For more information, see Hibernate ORM UserType and CompositeUserType changes.
    • Various JDBC types were moved to an internal package. To map your attributes to these types, use @JdbcTypeCode instead of @JdbcType.
    • The LockOptions class was deprecated; impacted methods have alternatives involving LockMode. Some deprecated features of the LockOptions class have also been removed. For more information, see Hibernate ORM LockOptions.
    • The Session#getLobHelper method is deprecated. Use Hibernate#getLobHelper instead. For more information, see Hibernate ORM Session#getLobHelper.
  • Behavior changes

    • Stricter annotation validation

      Misplaced mapping annotations now raise exceptions instead of being ignored. Examples include conflicting @Basic and @ManyToOne annotations on the same attribute, or the use of attribute converters on @Id and @Version. For more information, see Hibernate ORM Domain model validations.

    • Second-level cache usage

      StatelessSession now uses the second-level cache by default. This change impacts migrating applications that use second-level cache and StatelessSession. For more information, see Hibernate ORM StatelessSession and second-Level cache.

    • Batch operation changes

      StatelessSession does not respect the quarkus.hibernate-orm.jdbc.statement-batch-size setting. Because StatelessSession operations are designed to execute immediately, implicit batch operations are not required. Instead, you can use explicit batch operations such as 'insertMultiple()'. For more information, see Hibernate ORM StatelessSession and JDBC batching.

    • Query validation

      Ambiguous query strings are no longer accepted. This mainly affects type-unsafe queries, when not passing a class to Session#createQuery, or when using Panache to create a query. Queries without a select clause, but with a non-fetch join, must now specify the intended behavior. For more information, see Hibernate ORM Query with implicit SELECT and no explicit result type.

    • Changes to types returned for date and time values by native queries

      Previously, java.sql types were used to represent date and time types returned by a native query. Now, native queries return java.time types in the absence of specific type instructions. For more information, see Hibernate ORM Temporal types returned by native queries.

  • Minimum database versions

    The minimum required database versions have been updated to use the oldest version still supported by the respective vendor.

    In particular, note the following updates:

    • IBM DB2: minimum version updated from 10.5 to 11.1
    • MariaDB: minimum version updated from 10.4 to 10.6
    • Microsoft SQL Server: minimum version updated from 11.0 (2012) to 12.0 (2014)
    • PostgreSQL: minimum version updated from 12.0 to 13.0

      For more information about current minimum versions, see Hibernate ORM Supported dialects.

  • MySQL/MariaDB storage engine

    Using quarkus.hibernate-orm.dialect.storage-engine to set the MySQL/MariaDB storage engine has been deprecated. Use quarkus.hibernate-orm.dialect.mariadb.storage-engine=…​ or quarkus.hibernate-orm.dialect.mysql.storage-engine=…​ instead.

  • DDL/schema changes

    • The custom database initialization script, in particular on H2 databases, might need to change to avoid the use of quotes.
    • Basic arrays are now mapped to proper array structures in a database instead of being serialized as binary data. You can revert this behavior by setting quarkus.hibernate-orm.unsupported-properties."hibernate.type.preferred_array_jdbc_type" to VARBINARY. Otherwise, if your entity mapping includes arrays, updates to the database schema and a manual update of data are needed. For more information, see Hibernate ORM Array mapping changes.
    • char/Character attributes are now mapped to varchar(1) instead of char(1).
    • On Oracle and Microsoft SQL Server, timestamp attributes have a different default sub-second precision.
    • On Oracle, float and double attributes are mapped to binary_float and binary_double instead of float(p), real, or double precision types. For more information, see Hibernate ORM Changes affecting DDL.
  • Annotation processor changes

    • The Maven artifact for the Hibernate ORM annotation processor has changed from org.hibernate.orm:hibernate-jpamodelgen to org.hibernate.orm:hibernate-processor. In Maven, update the annotationProcessorPath.
    • The annotation processor org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor is deprecated in favor of org.hibernate.processor.HibernateProcessor.

      To apply this change, run the automatic update process described in the Migrating applications to Red Hat build of Quarkus 3.27 guide.

  • Contexts and dependency injection (CDI) restrictions for Hibernate ORM components

    • Some pluggable components, that are potentially retrieved before CDI is initialized, can no longer be CDI beans.

      If you need to provide a custom implementation of such components, and need access to CDI within that implementation, consider retrieving other beans by using Arc.container().instance(OtherBean.class).get(). For a list of impacted components, see the Migration guide 3.24.

  • JSON/XML mapping

    Previously, Hibernate ORM’s "format mappers" for JSON/XML serialization in the database relied on global REST layer serialization settings by default.

    Now, it is preferred to separate database layer and REST layer serialization to help ensure database format stability and prevent unnecessary migrations. However, because of this, the current release fails by default if the following conditions are met:

    • Your application has a Hibernate mapping involving XML or JSON stored in the database.
    • The XML or JSON serialization settings for the REST layer are customized.

    Should this occur, you can update your database serialization settings:

    • Jackson-based JSON serialization

      If the ObjectMapper customization applied in your application does not affect the format of the JSON stored in the database, bypass that ObjectMapper by specifying quarkus.hibernate-orm.mapping.format.global=ignore.

      Otherwise, implement a custom FormatMapper bean. First, delegate a format mapper to the global REST layer serialization.

      For more information, see the Migration guide 3.26 and the Customizing JSON/XML serialization/deserialization section of the Quarkus "Using Hibernate ORM and Jakarta Persistence" guide.

      Then, take either of the following actions:

      • Continue to use this delegating format mapper if you want to rely on the globally configured ObjectMapper and depend on the REST layer serialization needs.
      • Prepare and test migration scripts to update your JSON data. You can use either Hibernate ORM’s default format or adapt the FormatMapper implementation to format JSON according to your needs.
    • JSON-B-based JSON serialization

      This scenario is identical to that of the Jackson-based mapper. For more information, see the Migration guide 3.26.

    • JAXB-based XML serialization

      The XML serialization format change in Hibernate ORM 7.0 also has an impact. While the Quarkus built-in JAXB-based XML format mapper uses the legacy format, removing or bypassing it with quarkus.hibernate-orm.mapping.format.global=ignore makes the format incompatible.

      To mitigate, create a mapper that delegates to Hibernate ORM’s mapper. For more information, see the Migration guide 3.26.

      Then, take either of the following actions:

      • Continue to use this delegating format mapper if you want to rely on the legacy format.
      • Prepare and test migration scripts to update your XML data. You can use either Hibernate ORM’s default format or adapt the FormatMapper implementation to format XML according to your needs.

To apply this change, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

For more information, see the following resources:

1.4.3.6. Hibernate Reactive: Database version checks

In the current release, Hibernate Reactive validates database versions during startup.

This change ensures compatibility with supported databases and prevents applications from running against unsupported or incompatible versions.

If your application connects to a database version that does not meet Hibernate Reactive’s requirements, startup fails with a clear error message.

To resolve this issue, upgrade the database to a supported version or adjust your setup accordingly.

For more information, see the Quarkus Migration guide 3.25.

1.4.3.7. Hibernate Reactive: Upgraded to version 3.1

In the current release, Hibernate Reactive has been upgraded to version 3.1.

Hibernate Reactive 3.1 remains compatible with 3.0 for most applications, but it inherits breaking changes from Hibernate ORM.

For more information about the Hibernate ORM breaking changes, see the Hibernate ORM: Upgraded to version 7.1 release note.

The following Hibernate Reactive breaking changes are also introduced:

  • API changes

    The ReactiveIdentifierGenerator API is updated and now extends org.hibernate.generator.Generator, which requires additional methods.

    This change affects users who define a custom identifier generator by using the @GenericGenerator annotation and implement their own generator classes.

    To implement the new API, update custom identifier generators that are defined with @GenericGenerator.

    In the Generator interface, update the following methods:

    • generatedOnExecution(): Return true if the identifier is generated during query execution, or false if it is generated in your application code.
    • getEventTypes(): Specify if the identifier changes during an insert or update operation.
  • Minimum database versions

    The quarkus-hibernate-reactive extension aligns its minimum supported database versions with Hibernate ORM 7.1 dialect requirements. For more information about current minimum versions, see Hibernate ORM Supported dialects.

To apply this change, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

1.4.3.8. Hibernate Search: Upgraded to version 8.1

In the current release, Hibernate Search has been upgraded to version 8.1.

With the upgrade to the 8.x version series, some breaking changes are introduced that might impact your applications.

  • Deprecated classes are removed in favor of their recommended alternatives. Notably, org.hibernate.search.mapper.orm.massindexing.MassIndexingMonitor has been replaced by org.hibernate.search.mapper.pojo.massindexing.MassIndexingMonitor.
  • The MassIndexingMonitor#addToTotalCount method is deprecated and replaced by MassIndexingMonitor#typeGroupMonitor(..)
  • multi() methods in the projection DSL are deprecated and replaced by .list()/.set()/sortedSet()/collector(…​).
  • Logging categories have been updated. In particular, the org.hibernate.search.elasticsearch.request logging category, used for logging every request sent to Elasticsearch, has been renamed to org.hibernate.search.elasticsearch.client.request. For more information, see List of all available logging categories.
  • Search DSL interfaces are enhanced to include an extra SR type argument reference guide .
  • The format of mass indexing logs has changed to present more information in a condensed format.
  • Metric aggregation countDistinct() is deprecated and replaced by an option in count() aggregation: .count().field(..).distinct().

For more information, see the following resources:

1.4.4. Messaging

1.4.4.1. Apache Kafka: client upgraded to version 4.0.0

In the current release, the Apache Kafka client artifact, kafka-clients, which is used in the quarkus-kafka-client extension, has been upgraded to version 4.0.0.

This version introduces the following changes:

  • Removal of ZooKeeper dependency
  • Support for some older protocols or API versions is removed
  • Incompatibility with older clients or brokers that rely on deprecated features
  • A minimum requirement for Java version 11 for your Quarkus application
  • Improvements to client metrics

You can still connect to Apache Kafka 3.x brokers. Older brokers that rely on removed protocol versions might be incompatible.

For more information, see the following resources:

1.4.5. Observability

1.4.5.1. OpenTelemetry: Changes to metrics

In the current release, the OpenTelemetry metrics provided by the quarkus-opentelemetry extension have changed.

Note

By default, OpenTelemetry metrics are disabled. When enabled, by setting quarkus.otel.metrics.enabled=true, metrics related to the JVM and the HTTP server are collected.

The following table lists the OpenTelemetry metrics that are now available. Note that jvm.system.cpu.utilization metric is removed in JVM mode; use jvm.cpu.recent_utilization instead.

Expand
Metric nameDescriptionTypeAvailable on JVMAvailable on NativeMP Telemetry 2.0

http.server.request.duration

Duration of HTTP server requests

HISTOGRAM

Y

Y

Y

jvm.memory.committed

Measure of memory committed

LONG_SUM

Y

No data produced

Y

jvm.memory.used

Measure of memory used

LONG_SUM

Y

No data produced

Y

jvm.memory.limit

Measure of max obtainable memory

LONG_SUM

Y

Not present

Y

jvm.memory.used_after_last_gc

Measure of memory used, as measured after the most recent garbage collection event on this pool

LONG_SUM

Y

No data produced

Y

jvm.gc.duration

Duration of JVM garbage collection actions

HISTOGRAM

Y

Not present

Y

jvm.class.count

Number of classes currently loaded

LONG_SUM

Y

No data produced

Y

jvm.class.loaded

Number of classes loaded since JVM start

LONG_SUM

Y

No data produced

Y

jvm.class.unloaded

Number of classes unloaded since JVM start

LONG_SUM

Y

No data produced

Y

jvm.cpu.count

Number of processors available to the JVM

LONG_SUM

Y

Y

N

jvm.cpu.limit

 

LONG_SUM

Y

No data produced

N

jvm.cpu.time

CPU time used by the process as reported by the JVM

DOUBLE_SUM

Y

Not present

N

jvm.system.cpu.utilization

CPU time used by the process as reported by the JVM

DOUBLE_SUM

Not present

No data produced

N

jvm.cpu.recent_utilization

Recent CPU utilization for the process as reported by the JVM

DOUBLE_GAUGE

Y

No data produced

N

jvm.cpu.longlock

Long lock times

HISTOGRAM

Y

Y

N

jvm.cpu.context_switch

 

DOUBLE_SUM

Y

No data produced

N

jvm.network.io

Network read/write bytes

HISTOGRAM

Y

Not present

N

jvm.network.time

Network read/write duration

HISTOGRAM

Y

Not present

N

jvm.thread.count

Number of executing platform threads

LONG_SUM

Y

Y

Y

To apply this change, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

For more information, see the following resources:

1.4.6. Security

1.4.6.1. HTTP Authentication: Deprecated getCredentialTransport() method removed

In the current release, the deprecated blocking HttpAuthenticationMechanism.getCredentialTransport() method is removed.

If your application or a custom security extension overrides this method, you must update the implementation to avoid compilation errors.

Replace the removed method by implementing the reactive version, as in the following example:

Uni<HttpCredentialTransport> getCredentialTransport(RoutingContext context) {
    return Uni.createFrom().item(myHttpCredentialTransport);
}
Copy to Clipboard Toggle word wrap

To apply this change, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

1.4.6.2. TLS Registry extension restructuration

In the current release, the TLS Registry extension (quarkus-tls-registry) has been restructured to avoid having a split package between the runtime and spi modules.

As part of this reorganization, the io.quarkus.tls.TlsRegistryBuildItem class has been renamed to io.quarkus.tls.deployment.spi.TlsRegistryBuildItem. It is still located in the spi module.

If you have existing code that references the earlier TlsRegistryBuildItem class location, update your imports to use the current package:

// Earlier import
import io.quarkus.tls.TlsRegistryBuildItem;

// Current import
import io.quarkus.tls.deployment.spi.TlsRegistryBuildItem;
Copy to Clipboard Toggle word wrap

This change aligns with the architectural improvements proposed in the Quarkus project to maintain clearer separation between deployment and runtime components.

To apply this change, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

1.4.7. Tooling

1.4.7.1. Extension developers: Support for legacy config classes removed

Breaking change: Support for building extensions with legacy config classes and the -AlegacyConfigRoot=true annotation processor option has been removed.

Extensions must now use config interfaces annotated with @ConfigMapping and @ConfigRoot.

To apply this change, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

For more information, see the following resources:

1.4.7.2. Gradle: testNative and quarkusIntTest tasks no longer depend on the test task

In the current release, the Gradle tasks testNative and quarkusIntTest no longer depend on the test task.

Now, they execute only the native tests and the integration tests respectively, allowing independent test execution stages.

Update your build scripts if you previously relied on the default task dependency that included unit tests when running native or integration tests.

To apply this change, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

For more information, see the Quarkus Migration guide 3.22.

1.4.8. Web

1.4.8.1. ContextResolver: Lambda use in REST Client forbidden

In the current release, defining a ContextResolver in REST Client with a lambda throws an IllegalArgumentException.

This occurs because the REST Client extension cannot infer the generic type, unlike previous versions that defaulted to Object.

Replace lambdas with concrete ContextResolver implementations to avoid runtime errors and ensure correct REST Client configuration.

To apply this change, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

For more information, see the Quarkus Migration guide 3.22.

1.4.8.2. Panache REST: Jakarta REST resources restricted to Quarkus REST

In the current release, Jakarta REST resource classes that use Panache work only with Quarkus REST modules.

REST Data Panache modules no longer work with RESTEasy Classic modules.

A list of the affected modules:

  • quarkus-hibernate-orm-rest-data-panache
  • quarkus-hibernate-reactive-rest-data-panache
  • quarkus-mongodb-rest-data-panache
  • spring-data-rest

Use Quarkus REST, quarkus-rest-*, instead of RESTEasy Classic, quarkus-resteasy-*, to avoid runtime failures.

To apply this change, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

For more information, see the Quarkus Migration guide 3.22.

1.4.8.3. REST: JsonView deserialization behavior changed

In the current release, Quarkus REST applies @JsonView consistently to both serialization and deserialization.

@JsonView on resource methods or DTOs now controls which properties are read from input and written to output according to the specified view classes (for example, Views.Public and Views.Private).

Previously, only serialization honored @JsonView, so deserialization might have accepted properties outside the active view. Applications that relied on that behavior might require code or configuration changes to align with the new behavior.

To apply this change, manually perform any additional steps described in this release note. The automatic update process in the Migrating applications to Red Hat build of Quarkus 3.27 guide do not cover this change.

For more information, see the Quarkus Migration guide 3.21.

Legal Notice

Copyright © 2025 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat