quarkusio · gsmet · Sep 25, 2024 · Sep 17, 2024 · Sep 18, 2024 · Sep 18, 2024
diff --git a/bom/application/pom.xml b/bom/application/pom.xml
@@ -182,7 +182,7 @@
         <mockito.version>5.12.0</mockito.version>
         <jna.version>5.8.0</jna.version><!-- should satisfy both testcontainers and mongodb -->
         <quarkus-security.version>2.1.0</quarkus-security.version>
-        <keycloak.version>25.0.2</keycloak.version>
+        <keycloak.version>25.0.6</keycloak.version>
         <logstash-gelf.version>1.15.1</logstash-gelf.version>
         <checker-qual.version>3.46.0</checker-qual.version>
         <error-prone-annotations.version>2.30.0</error-prone-annotations.version>

diff --git a/build-parent/pom.xml b/build-parent/pom.xml
@@ -95,7 +95,7 @@
 
         <!-- The image to use for tests that run Keycloak -->
         <!-- IMPORTANT: If this is changed you must also update bom/application/pom.xml and KeycloakBuildTimeConfig/DevServicesConfig in quarkus-oidc/deployment to match the version -->
-        <keycloak.version>25.0.2</keycloak.version>
+        <keycloak.version>25.0.6</keycloak.version>
         <keycloak.wildfly.version>19.0.3</keycloak.wildfly.version>
         <keycloak.docker.image>quay.io/keycloak/keycloak:${keycloak.version}</keycloak.docker.image>
         <keycloak.docker.legacy.image>quay.io/keycloak/keycloak:${keycloak.wildfly.version}-legacy</keycloak.docker.legacy.image>

diff --git a/...fig-doc-maven-plugin/src/main/resources/templates/tags/configProperty.qute.adoc b/...fig-doc-maven-plugin/src/main/resources/templates/tags/configProperty.qute.adoc
@@ -1,4 +1,4 @@
-a|{#if configProperty.phase.fixedAtBuildTime}icon:lock[title=Fixed at build time]{/if} [[{configProperty.toAnchor(extension, additionalAnchorPrefix)}]] [.property-path]##`{configProperty.path}`##
+a|{#if configProperty.phase.fixedAtBuildTime}icon:lock[title=Fixed at build time]{/if} [[{configProperty.toAnchor(extension, additionalAnchorPrefix)}]] [.property-path]##link:#{configProperty.toAnchor(extension, additionalAnchorPrefix)}[`{configProperty.path}`]##
 {#for additionalPath in configProperty.additionalPaths}
 
 `{additionalPath}`

diff --git a/...nfig-doc-maven-plugin/src/main/resources/templates/tags/configSection.qute.adoc b/...nfig-doc-maven-plugin/src/main/resources/templates/tags/configSection.qute.adoc
@@ -1,4 +1,4 @@
-h|[[{configSection.toAnchor(extension, additionalAnchorPrefix)}]] [.section-name.section-level{configSection.level}]##{configSection.formatTitle.escapeCellContent}##
+h|[[{configSection.toAnchor(extension, additionalAnchorPrefix)}]] [.section-name.section-level{configSection.level}]##link:#{configSection.toAnchor(extension, additionalAnchorPrefix)}[{configSection.formatTitle.escapeCellContent}]##
 h|Type
 h|Default
 

diff --git a/docs/src/main/asciidoc/picocli.adoc b/docs/src/main/asciidoc/picocli.adoc
@@ -297,7 +297,8 @@

 == Development Mode
 
 In the development mode, i.e. when running `mvn quarkus:dev`, the application is executed and restarted every time the `Space bar` key is pressed. You can also pass arguments to your command line app via the `quarkus.args` system property, e.g. `mvn quarkus:dev -Dquarkus.args='--help'` and `mvn quarkus:dev -Dquarkus.args='-c -w --val 1'`.
+For Gradle projects, arguments can be passed using `--quarkus-args`.
 
 == Kubernetes support
 

diff --git a/docs/src/main/asciidoc/qute-reference.adoc b/docs/src/main/asciidoc/qute-reference.adoc
@@ -2395,12 +2395,12 @@ public class Statuses {
     public static final String OFF = "off";
 }
 ----
-<1> A name resolver with the namespace `model_Status` is generated automatically.
+<1> A name resolver with the namespace `model_Statuses` is generated automatically.
 
 .Template Accessing Class Constants
 [source,html]
 ----
-{#if machine.status == model_Status:ON}
+{#if machine.status == model_Statuses:ON}
   The machine is ON!
 {/if}
 ----

diff --git a/docs/src/main/asciidoc/rabbitmq.adoc b/docs/src/main/asciidoc/rabbitmq.adoc
@@ -398,14 +398,14 @@ You just need to run both applications using:
 
 [source,bash]
 ----
-> mvn -f rabbitmq-quickstart-producer quarkus:dev
+mvn -f rabbitmq-quickstart-producer quarkus:dev
 ----
 
 And, in a separate terminal:
 
 [source, bash]
 ----
-> mvn -f rabbitmq-quickstart-processor quarkus:dev
+mvn -f rabbitmq-quickstart-processor quarkus:dev
 ----
 
 Quarkus starts a RabbitMQ broker automatically, configures the application and shares the broker instance between different applications.
@@ -469,8 +469,8 @@ First, make sure you stopped the applications, and build both applications in JV
 
 [source, bash]
 ----
-> mvn -f rabbitmq-quickstart-producer clean package
-> mvn -f rabbitmq-quickstart-processor clean package
+mvn -f rabbitmq-quickstart-producer clean package
+mvn -f rabbitmq-quickstart-processor clean package
 ----
 
 Once packaged, run `docker compose up --build`.
@@ -480,17 +480,17 @@ To run your applications as native, first we need to build the native executable
 
 [source, bash]
 ----
-> mvn -f rabbitmq-quickstart-producer package -Dnative  -Dquarkus.native.container-build=true
-> mvn -f rabbitmq-quickstart-processor package -Dnative -Dquarkus.native.container-build=true
+mvn -f rabbitmq-quickstart-producer package -Dnative  -Dquarkus.native.container-build=true
+mvn -f rabbitmq-quickstart-processor package -Dnative -Dquarkus.native.container-build=true
 ----
 
 The `-Dquarkus.native.container-build=true` instructs Quarkus to build Linux 64bits native executables, who can run inside containers.
 Then, run the system using:
 
 [source, bash]
 ----
-> export QUARKUS_MODE=native
-> docker compose up --build
+export QUARKUS_MODE=native
+docker compose up --build
 ----
 
 As before, the UI is exposed on http://localhost:8080/quotes.html

diff --git a/docs/src/main/asciidoc/security-keycloak-authorization.adoc b/docs/src/main/asciidoc/security-keycloak-authorization.adoc
@@ -226,7 +226,7 @@ To start a Keycloak server, use the following Docker command:
 docker run --name keycloak -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin -p 8543:8443 -v "$(pwd)"/config/keycloak-keystore.jks:/etc/keycloak-keystore.jks quay.io/keycloak/keycloak:{keycloak.version} start  --hostname-strict=false --https-key-store-file=/etc/keycloak-keystore.jks
 ----
 
-where `keycloak.version` must be `25.0.2` or later and the `keycloak-keystore.jks` can be found in https://github.com/quarkusio/quarkus-quickstarts/blob/main/security-keycloak-authorization-quickstart/config/keycloak-keystore.jks[quarkus-quickstarts/security-keycloak-authorization-quickstart/config].
+where `keycloak.version` must be `25.0.6` or later and the `keycloak-keystore.jks` can be found in https://github.com/quarkusio/quarkus-quickstarts/blob/main/security-keycloak-authorization-quickstart/config/keycloak-keystore.jks[quarkus-quickstarts/security-keycloak-authorization-quickstart/config].
 
 Try to access your Keycloak server at https://localhost:8543[localhost:8543].
 

diff --git a/docs/src/main/asciidoc/security-oidc-bearer-token-authentication-tutorial.adoc b/docs/src/main/asciidoc/security-oidc-bearer-token-authentication-tutorial.adoc
@@ -217,7 +217,7 @@ For more information, see the <<bearer-token-tutorial-keycloak-dev-mode>> sectio
 docker run --name keycloak -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin -p 8180:8080 quay.io/keycloak/keycloak:{keycloak.version} start-dev
 ----
 ====
-* Where the `keycloak.version` is set to version `25.0.2` or later.
+* Where the `keycloak.version` is set to version `25.0.6` or later.
 . You can access your Keycloak server at http://localhost:8180[localhost:8180].
 . To access the Keycloak Administration console, log in as the `admin` user by using the following login credentials:
 

diff --git a/docs/src/main/asciidoc/security-oidc-code-flow-authentication-tutorial.adoc b/docs/src/main/asciidoc/security-oidc-code-flow-authentication-tutorial.adoc
@@ -201,7 +201,7 @@ To start a Keycloak server, use Docker and run the following command:
 docker run --name keycloak -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin -p 8180:8080 quay.io/keycloak/keycloak:{keycloak.version} start-dev
 ----
 
-where `keycloak.version` is set to `25.0.2` or later.
+where `keycloak.version` is set to `25.0.6` or later.
 
 You can access your Keycloak Server at http://localhost:8180[localhost:8180].
 

diff --git a/docs/src/main/asciidoc/security-openid-connect-client.adoc b/docs/src/main/asciidoc/security-openid-connect-client.adoc
@@ -507,7 +507,7 @@ To start a Keycloak Server, you can use Docker and just run the following comman
 docker run --name keycloak -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin -p 8180:8080 quay.io/keycloak/keycloak:{keycloak.version} start-dev
 ----
 
-Set `{keycloak.version}` to `25.0.2` or later.
+Set `{keycloak.version}` to `25.0.6` or later.
 
 You can access your Keycloak Server at http://localhost:8180[localhost:8180].
 

diff --git a/docs/src/main/asciidoc/security-openid-connect-dev-services.adoc b/docs/src/main/asciidoc/security-openid-connect-dev-services.adoc
@@ -258,7 +258,7 @@ For more information, see xref:security-oidc-bearer-token-authentication.adoc#be
 [[keycloak-initialization]]
 === Keycloak initialization
 
-The `quay.io/keycloak/keycloak:25.0.2` image which contains a Keycloak distribution powered by Quarkus is used to start a container by default.
+The `quay.io/keycloak/keycloak:25.0.6` image which contains a Keycloak distribution powered by Quarkus is used to start a container by default.
 `quarkus.keycloak.devservices.image-name` can be used to change the Keycloak image name.
 For example, set it to `quay.io/keycloak/keycloak:19.0.3-legacy` to use a Keycloak distribution powered by WildFly.
 Be aware that a Quarkus-based Keycloak distribution is only available starting from Keycloak `20.0.0`.

diff --git a/docs/src/main/asciidoc/security-openid-connect-multitenancy.adoc b/docs/src/main/asciidoc/security-openid-connect-multitenancy.adoc
@@ -356,9 +356,9 @@
 docker run --name keycloak -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=admin -p 8180:8080 quay.io/keycloak/keycloak:{keycloak.version} start-dev
 ----
 
-where `keycloak.version` is set to `25.0.2` or higher.
+where `keycloak.version` is set to `25.0.6` or higher.
 
 Access your Keycloak server at http://localhost:8180[localhost:8180].
 
 Log in as the `admin` user to access the Keycloak administration console.
 The username and password are both `admin`.
@@ -894,21 +894,23 @@
 
 Tenant resolution for the OIDC `web-app` applications must be done at least 3 times during an authorization code flow, when the OIDC tenant-specific configuration affects how each of the following steps is run.
 
-==== Step 1: Unauthenticated user accesses an endpoint and is redirected to OIDC provider
+.Step 1: Unauthenticated user accesses an endpoint and is redirected to OIDC provider
 
 When an unauthenticated user accesses a secured path, the user is redirected to the OIDC provider to authenticate and the tenant configuration is used to build the redirect URI.
 
 All the static and dynamic tenant resolution options listed in the <<static-tenant-resolution>> and <<tenant-config-resolver>> sections can be used to resolve a tenant.
 
-==== Step 2: The user is redirected back to the endpoint
+.Step 2: The user is redirected back to the endpoint
 
 After the provider authentication, the user is redirected back to the Quarkus endpoint and the tenant configuration is used to complete the authorization code flow.
 
 All the static and dynamic tenant resolution options listed in the <<static-tenant-resolution>> and <<tenant-config-resolver>> sections can be used to resolve a tenant. Before the tenant resolution begins, the authorization code flow `state cookie` is used to set the already resolved tenant configuration id as a RoutingContext `tenant-id` attribute: both custom dynamic `TenantConfigResolver` and static `TenantResolver` tenant resolvers can check it.
 
-==== Step 3: Authenticated user accesses the secured path using the session cookie: the tenant configuration determines how the session cookie is verified and refreshed. Before the tenant resolution begins, the authorization code flow `session cookie` is used to set the already resolved tenant configuration id as a RoutingContext `tenant-id` attribute: both custom dynamic `TenantConfigResolver` and static `TenantResolver` tenant resolvers can check it.
+.Step 3: Authenticated user accesses the secured path using the session cookie
+
+The tenant configuration determines how the session cookie is verified and refreshed. Before the tenant resolution begins, the authorization code flow `session cookie` is used to set the already resolved tenant configuration id as a RoutingContext `tenant-id` attribute: both custom dynamic `TenantConfigResolver` and static `TenantResolver` tenant resolvers can check it.
 
 For example, here is how a custom `TenantConfigResolver` can avoid creating the already resolved tenant configuration, that may otherwise require blocking reads from the database or other remote sources:
 
 [source,java]
 ----

diff --git a/docs/src/main/asciidoc/smallrye-graphql-client.adoc b/docs/src/main/asciidoc/smallrye-graphql-client.adoc
@@ -287,7 +287,7 @@ to properly qualify the injection point.
 If you need to add an authorization header, or any other custom HTTP header (in our case
 it's not required), this can be done by:
 ----
-quarkus.smallrye-graphql-client.star-wars-dynamic.header.HEADER-KEY=HEADER-VALUE"
+quarkus.smallrye-graphql-client.star-wars-dynamic.header.HEADER-KEY=HEADER-VALUE
 ----
 
 Add this to the `StarWarsResource` created earlier:

diff --git a/docs/src/main/asciidoc/spring-data-jpa.adoc b/docs/src/main/asciidoc/spring-data-jpa.adoc
@@ -416,7 +416,9 @@ Interfaces that extend any of the following Spring Data repositories are automat
 
 * `org.springframework.data.repository.Repository`
 * `org.springframework.data.repository.CrudRepository`
+* `org.springframework.data.repository.ListCrudRepository`
 * `org.springframework.data.repository.PagingAndSortingRepository`
+* `org.springframework.data.repository.ListPagingAndSortingRepository`
 * `org.springframework.data.jpa.repository.JpaRepository`
 
 The generated repositories are also registered as beans so they can be injected into any other bean.

diff --git a/docs/src/main/asciidoc/spring-data-rest.adoc b/docs/src/main/asciidoc/spring-data-rest.adoc
@@ -327,15 +327,15 @@ The former is used by default, but it is highly recommended to specify which one
 If a database contains many entities, it might not be a great idea to return them all at once.
 `PagingAndSortingRepository` allows the `spring-data-rest` extension to access data in chunks.
 
-Replace the `CrudRepository` with `PagingAndSortingRepository` in the `FruitsRepository`:
+So, you can extend the `PagingAndSortingRepository`:
 
 [source,java]
 ----
 package org.acme.spring.data.rest;
 
 import org.springframework.data.repository.PagingAndSortingRepository;
 
-public interface FruitsRepository extends PagingAndSortingRepository<Fruit, Long> {
+public interface FruitsRepository extends CrudRepository<Fruit, Long>, PagingAndSortingRepository<Fruit, Long> {
 }
 ----
 
@@ -362,6 +362,19 @@ Now the `GET /fruits` will accept three new query parameters: `sort`, `page` and
 
 For paged responses, `spring-data-rest` also returns a set of link headers that can be used to access other pages: first, previous, next and last.
 
+Additionally, rather than extending both `PagingAndSortingRepository` and `CrudRepository`, you can use `JpaRepository`, which is a higher-level abstraction tailored for JPA. Since `JpaRepository` already extends both `PagingAndSortingRepository` and `CrudRepository`, it can replace `CrudRepository` directly.
+
+[source,java]
+----
+package org.acme.spring.data.rest;
+
+import org.springframework.data.repository.PagingAndSortingRepository;
+
+public interface FruitsRepository extends JpaRepository<Fruit, Long> {
+}
+----
+
+
 ==== Fine tuning endpoints generation
 
 This allows user to specify which methods should be exposed and what path should be used to access them.

diff --git a/docs/src/main/asciidoc/tls-registry-reference.adoc b/docs/src/main/asciidoc/tls-registry-reference.adoc
@@ -768,7 +768,6 @@ The generated secret includes the following files:
 
 == Working with OpenShift serving certificates
 
-When running your application in OpenShift, you can use the link:https://docs.openshift.com/container-platform/4.16/security/certificates/service-serving-certificate.html[OpenShift serving certificates] to generate and renew TLS certificates automatically.
 When running your application in OpenShift, you can use the link:https://docs.openshift.com/container-platform/4.16/security/certificates/service-serving-certificate.html[OpenShift serving certificates] to generate and renew TLS certificates automatically.
 The Quarkus TLS registry can use these certificates and Certificate Authority (CA) files to handle HTTPS traffic and validate certificates securely.
 

diff --git a/...ployment/src/main/java/io/quarkus/azure/functions/deployment/AzureFunctionsProcessor.java b/...ployment/src/main/java/io/quarkus/azure/functions/deployment/AzureFunctionsProcessor.java
@@ -213,7 +213,7 @@ public void findFunctions(CombinedIndexBuildItem combined,
                 Class declaring = loader.loadClass(ci.name().toString());
                 Class[] params = methodInfo.parameters().stream().map(methodParameterInfo -> {
                     try {
-                        return loader.loadClass(methodParameterInfo.type().name().toString());
+                        return Class.forName(methodParameterInfo.type().name().toString(), false, loader);
                     } catch (ClassNotFoundException e) {
                         throw new DeploymentException(e);
                     }