Sync web site with Quarkus documentation

Author: quarkusbot

_generated-doc/latest/infra/quarkus-maven-plugin-goals.adoc

@@ -4014,10 +4014,6 @@ a| [[quarkus-maven-plugin-goal-update-bomVersion]] bomVersion
 |`String`
 |
 
-a| [[quarkus-maven-plugin-goal-update-mavenSession]] mavenSession
-|`MavenSession`
-|`${session}`
-
 a| [[quarkus-maven-plugin-goal-update-noRewrite]] noRewrite
 
 [.description]

_guides/_attributes.adoc

@@ -1,7 +1,7 @@
 // Common attributes.
 // --> No blank lines (it ends the document header)
 :project-name: Quarkus
-:quarkus-version: 3.26.0
+:quarkus-version: 3.26.1
 :quarkus-platform-groupid: io.quarkus.platform
 // .
 :maven-version: 3.9.9

_guides/compose-dev-services.adoc

@@ -645,6 +645,8 @@ Compose Dev Services won't try to discover any services and will be disabled.
 === Compose Dev Services used for tests
 
 For Quarkus tests, a generated project name in the format `quarkus-devservices-<application-name>-<random-suffix>` is used by default to ensure isolation between test runs and running dev mode services.
+If the top-level name attribute is specified in the Compose file, the project name in the format `<compose-name>-<random-suffix>` is used.
+
 This way, Quarkus tests start a separate copy of the services defined in the compose files.
 For example, when running continuous testing in development mode, tests will have their own isolated set of services.
 

_guides/config-reference.adoc

@@ -367,7 +367,7 @@ Setting `quarkus.profile`  to `staging` will activate the `staging` profile.
 
 [NOTE]
 ====
-The `io.smallrye.config.SmallRyeConfig#getProfiles` API provides a way to retrieve the active profiles programmatically.
+The `io.quarkus.runtime.configuration.ConfigUtils.getProfiles` API provides a way to retrieve the active profiles programmatically.
 ====
 
 === Profile-aware files

_guides/datasource.adoc

@@ -678,9 +678,15 @@ You can override this by setting the `transactions` configuration property:
 * `quarkus.datasource.jdbc.transactions` for default unnamed datasource
 * `quarkus.datasource._<datasource-name>_.jdbc.transactions` for named datasource
 
-When a datasource is enabled for XA (by setting `quarkus.datasource[.optional name].jdbc.transactions` to `xa`) and the transaction recovery system is enabled (by setting the property `quarkus.transaction-manager.enable-recovery` to `true`), then the datasource is automatically registered for recovery.
-This is a safe default, but you can override this behaviour on a per-datasource basis by setting `quarkus.datasource.jdbc.enable-recovery` or `quarkus.datasource."datasource-name".jdbc.enable-recovery` to `false`.
-Use only for advanced use cases and if you know recovery will not be necessary; otherwise it can result in data loss, data unavailability, or both, because resources can become locked indefinitely.
+When a datasource is configured for XA transactions by setting `quarkus.datasource[.optional name].jdbc.transactions=xa` and the transaction recovery system is enabled by using `quarkus.transaction-manager.enable-recovery=true`, the datasource is automatically registered for recovery.
+This is the preferred and safe default.
+You can override this behavior for individual datasources by setting `quarkus.datasource.jdbc.enable-recovery=false` or `quarkus.datasource."datasource-name".jdbc.enable-recovery=false`.
+
+[IMPORTANT]
+====
+Change this setting only in advanced use cases and only if you are certain recovery is not required.
+Incorrect configuration can lead to data loss, data unavailability, or both, due to resources remaining locked indefinitely.
+====
 
 For more information, see the <<configuration-reference,Configuration reference>> section below.
 To facilitate the storage of transaction logs in a database by using JDBC, see the xref:transaction.adoc#jdbcstore[Configuring transaction logs to be stored in a datasource] section of the xref:transaction.adoc[Using transactions in Quarkus] guide.

_guides/dev-ui.adoc

@@ -397,7 +397,7 @@ To add a tab to the Dev UI settings dialog, produce a `SettingPageBuildItem`:
     @BuildStep(onlyIf = IsLocalDevelopment.class) // <1>
     void createMCPSettingsTab(BuildProducer<SettingPageBuildItem> settingPageProducer) {
 
-        SettingPageBuildItem mcpSettingTab = new SettingPageBuildItem("Dev MCP");// <2>
+        SettingPageBuildItem mcpSettingTab = new SettingPageBuildItem();// <2>
 
         mcpSettingTab.addPage(Page.webComponentPageBuilder() // <3>
                 .title("Dev MCP")// <4>
@@ -438,7 +438,7 @@ To do this, produce a `UnlistedPageBuildItem`:
     @BuildStep(onlyIf = IsLocalDevelopment.class) // <1>
     void createMCPUnlistedPages(BuildProducer<UnlistedPageBuildItem> unlistedPageProducer) {
 
-        UnlistedPageBuildItem mcpOtherPages = new UnlistedPageBuildItem("Dev MCP"); // <2>
+        UnlistedPageBuildItem mcpOtherPages = new UnlistedPageBuildItem(); // <2>
 
         mcpOtherPages.addPage(Page.webComponentPageBuilder() // <3>
                 .title("Tools") // <4>

_guides/hibernate-orm.adoc

@@ -486,6 +486,13 @@ EntityManager entityManager;
 ----
 <1> Here again, we use the same `@io.quarkus.hibernate.orm.PersistenceUnit` annotation.
 
+[NOTE]
+====
+The injected `EntityManager` or `Session` instance is a proxy that requires an active transaction for interaction.
+
+By default it is also possible to use it for read-only operations without a transaction when in a request scope, but this can be disabled by setting `quarkus.hibernate-orm.request-scoped.enabled` to `false`.
+====
+
 You can inject the `EntityManagerFactory` of a named persistence unit using the exact same mechanism:
 
 [source,java]

_guides/platform.adoc

@@ -20,6 +20,7 @@ Each organization creating their Quarkus platform may establish their own criter
 
 == How does the Quarkus Platform help?
 When multiple extensions are used in the same project, a Quarkus platform BOM ensures:
+
 * version compatibility between the dependencies;
 * simplified dependency management;
 * easier upgrades.

_guides/security-authorize-web-endpoints-reference.adoc

@@ -13,9 +13,6 @@ include::_attributes.adoc[]
 Quarkus incorporates a pluggable web security layer.
 When security is active, the system performs a permission check on all HTTP requests to determine if they should proceed.
 
-Using `@PermitAll` will not open a path if the path is restricted by the `quarkus.http.auth.` configuration.
-To ensure specific paths are accessible, appropriate configurations must be made within the Quarkus security settings.
-
 [NOTE]
 ====
 If you use Jakarta RESTful Web Services, consider using `quarkus.security.jaxrs.deny-unannotated-endpoints` or `quarkus.security.jaxrs.default-roles-allowed` to set default security requirements instead of HTTP path-level matching because annotations can override these properties on an individual endpoint.
@@ -30,6 +27,11 @@ xref:security-customization.adoc#security-identity-customization[Security Identi
 
 Permissions are defined in the Quarkus configuration by permission sets, each specifying a policy for access control.
 
+[NOTE]
+====
+When a security policy's `paths` property contains the most specific path that matches the current request path, it takes precedence over other security policies with matching paths and is said to win.
+====
+
 .{project-name} policies summary
 [options="header"]
 |===
@@ -263,7 +265,7 @@ quarkus.http.auth.permission.public.policy=permit
 Previous examples demonstrated matching all sub-paths when a path concludes with the `$$*$$`
 wildcard.
 
-This wildcard also applies in the middle of a path, representing a single path segment.
+This wildcard can also be applied in the middle of a path, representing a single path segment.
 It cannot be mixed with other path segment characters; thus, path separators always enclose the `$$*$$` wildcard, as seen in the `/public/$$*$$/about-us` path.
 
 When several path patterns correspond to the same request path, the system selects the longest sub-path leading to the `$$*$$` wildcard.
@@ -425,7 +427,7 @@ For more information, see link:https://quarkus.io/blog/path-resolution-in-quarku
 [[map-security-identity-roles]]
 === Map `SecurityIdentity` roles
 
-Winning role-based policy can map the `SecurityIdentity` roles to the deployment-specific roles.
+The winning role-based policy that was chosen to authorize the current request can map `SecurityIdentity` roles to deployment-specific roles.
 These roles are then applicable for endpoint authorization by using the `@RolesAllowed` annotation.
 
 [source,properties]
@@ -466,7 +468,7 @@ public class HttpSecurityConfiguration {
 === Shared permission checks
 
 One important rule for unshared permission checks is that only one path match is applied, the most specific one.
-Naturally you can specify as many permissions with the same winning path as you want and they will all be applied.
+When a path matches as the most specific, you can specify multiple permissions for that path and they are all applied.
 However, there can be permission checks you want to apply to many paths without repeating them over and over again.
 That's where shared permission checks come in, they are always applied when the permission path is matched.
 
@@ -603,6 +605,13 @@ The same authorization can be required with the `@PermissionsAllowed(value = { "
 {project-name} includes built-in security to allow for link:https://en.wikipedia.org/wiki/Role-based_access_control[Role-Based Access Control (RBAC)]
 based on the common security annotations `@RolesAllowed`, `@DenyAll`, `@PermitAll` on REST endpoints and CDI beans.
 
+[NOTE]
+====
+Authorization checks for `quarkus.http.auth.` configurations are performed before security checks for standard security annotations.
+Therefore, `@PermitAll` only permits access to paths that are not already restricted by HTTP permissions.
+`@PermitAll` cannot override HTTP-level security configurations, only relax restrictions imposed by other standard security annotations such as `@RolesAllowed`.
+====
+
 .{project-name} annotation types summary
 [options="header"]
 |===
@@ -683,7 +692,10 @@ This returns `non-null` for a secured endpoint.
 <6> The `/subject/denied` endpoint declares the `@DenyAll` annotation, disallowing all direct access to it as a REST method, regardless of the user calling it.
 The method is still invokable internally by other methods in this class.
 
-CAUTION: If you plan to use standard security annotations on the IO thread, review the information in xref:security-proactive-authentication.adoc[Proactive Authentication].
+[CAUTION]
+====
+If you plan to use standard security annotations on the IO thread, review the information in xref:security-proactive-authentication.adoc[Proactive Authentication].
+====
 
 The `@RolesAllowed` annotation value supports xref:config-reference.adoc#property-expressions[property expressions] including default values and nested property expressions.
 Configuration properties used with the annotation are resolved at runtime.