Fix various typos

(cherry picked from commit 0c589cd)

docs/src/main/asciidoc/README.adoc

@@ -45,5 +45,5 @@ complete list of externalized variables for use is given in the following table:
 |\{quickstarts-tree-url}|{quickstarts-tree-url}| Quickstarts URL to main source tree root; used for referencing directories.
 
 |\{graalvm-version}|{graalvm-version}| Recommended GraalVM version to use.
-|\{graalvm-flavor}|{graalvm-flavor}| The full flavor of GraaVM to use e.g. `19.3.1-java11`. Make sure to use a `java11` version.
+|\{graalvm-flavor}|{graalvm-flavor}| The full flavor of GraalVM to use e.g. `19.3.1-java11`. Make sure to use a `java11` version.
 |===

docs/src/main/asciidoc/capabilities.adoc

@@ -7,7 +7,7 @@ https://github.com/quarkusio/quarkus/tree/main/docs/src/main/asciidoc
 
 include::./attributes.adoc[]
 
-Quarkus extensions may declare in their descriptors (`META-INF/quarkus-extension.properties` found in the runtime extension JAR artifact) that they provide certain capabilities. A capability represents a technical aspect, e.g. an implementation of some functionality or a specification. Each capability has a name which should follow the Java package naming convetion, e.g. `io.quarkus.rest`.
+Quarkus extensions may declare in their descriptors (`META-INF/quarkus-extension.properties` found in the runtime extension JAR artifact) that they provide certain capabilities. A capability represents a technical aspect, e.g. an implementation of some functionality or a specification. Each capability has a name which should follow the Java package naming convention, e.g. `io.quarkus.rest`.
 
 IMPORTANT: Only a single provider of any given capability is allowed in an application. If more than one provider of a capability is detected, the application build will fail with the corresponding error message.
 

docs/src/main/asciidoc/cdi-reference.adoc

@@ -593,7 +593,7 @@ public class TracerConfiguration {
 }
 ----
 
-TIP: `@IfBuildProperty` and `@UnlessBuildProperty` are repeatable annotations, i.e. a bean will only be enabled if **all** of the conditions defined by these annotations are satisifed.
+TIP: `@IfBuildProperty` and `@UnlessBuildProperty` are repeatable annotations, i.e. a bean will only be enabled if **all** of the conditions defined by these annotations are satisfied.
 
 If instead, it is required that the `RealTracer` bean is only used if the `some.tracer.enabled` property is not `false`, then `@UnlessBuildProperty` would be ideal. The code would look like:
 

docs/src/main/asciidoc/container-image.adoc

@@ -121,7 +121,7 @@ NOTE: If no registry is set (using `quarkus.container-image.registry`) then `doc
 
 == Selecting among multiple extensions
 
-It does not make sense to use multiple extension as part of the same build. When multiple container image extensions are present, an error will be raised to inform the user. The user can either remove the uneeded extensions or select one using `application.properties`.
+It does not make sense to use multiple extension as part of the same build. When multiple container image extensions are present, an error will be raised to inform the user. The user can either remove the unneeded extensions or select one using `application.properties`.
 
 For example, if both `container-image-docker` and `container-image-s2i` are present and the user needs to use `container-image-docker`:
 

docs/src/main/asciidoc/platform.adoc

@@ -12,7 +12,7 @@ The Quarkus extension ecosystem consists of the Quarkus extensions developed and
 == Quarkus Platform
 
 The fundamental promise of a Quarkus platform is any combination of the Quarkus extensions the platform consists of can be used in the same application without causing any conflict for each other.
-Each organization creating their Quarkus platform may establish their own criterions for the extensions to be accepted into the platform and the means to guarantee the compatibility between the accepted extensions.
+Each organization creating their Quarkus platform may establish their own criteria for the extensions to be accepted into the platform and the means to guarantee the compatibility between the accepted extensions.
 
 === Quarkus Platform Artifacts
 

docs/src/main/asciidoc/qute-reference.adoc

@@ -1585,9 +1585,9 @@ As a result, you may encounter template exceptions like `Property "name" not fou
 There are several ways to solve this problem:
 
 * Make use of <<typesafe_templates,type-safe templates>> or <<typesafe_expressions,type-safe expressions>>
-** In this case, an optimized value resolver is generated automatically and used at rutime
+** In this case, an optimized value resolver is generated automatically and used at runtime
 ** This is the preferred solution
-* Annotate the model class with <<template_data,`@TemplateData`>> - a specialized value resolver is generated and used at rutime
+* Annotate the model class with <<template_data,`@TemplateData`>> - a specialized value resolver is generated and used at runtime
 * Annotate the model class with `@io.quarkus.runtime.annotations.RegisterForReflection` to make the reflection-based value resolver work
 
 

docs/src/main/asciidoc/rest-json.adoc

@@ -240,7 +240,7 @@ public class CustomObjectMapper {
     ObjectMapper objectMapper(Instance<ObjectMapperCustomizer> customizers) {
         ObjectMapper mapper = myObjectMapper(); // Custom `ObjectMapper`
 
-        // Apply all ObjectMapperCustomerizer beans (incl. Quarkus)
+        // Apply all ObjectMapperCustomizer beans (incl. Quarkus)
         for (ObjectMapperCustomizer customizer : customizers) {
             customizer.customize(mapper);
         }

docs/src/main/asciidoc/security-built-in-authentication.adoc

@@ -111,7 +111,7 @@ This means that requests with an invalid credential will always be rejected, eve
 this behavior and only authenticate when required by setting `quarkus.http.auth.proactive=false`.
 
 If you disable proactive authentication then the authentication process will only be run when an identity is requested,
-either because there are security rules that requires the user to be authenticated, or due to programatic access to the
+either because there are security rules that requires the user to be authenticated, or due to programmatic access to the
 current identity.
 
 Note that if proactive authentication is in use accessing the `SecurityIdentity` is a blocking operation. This is because

docs/src/main/asciidoc/security-jwt.adoc

@@ -153,7 +153,7 @@ will produce undesirable behavior since JWT claims are naturally request scoped.
 <2> Here we inject the JsonWebToken interface, an extension of the java.security.Principal interface that provides access to the claims associated with the current authenticated token.
 <3> @PermitAll is a JSR 250 common security annotation that indicates that the given endpoint is accessible by any caller, authenticated or not.
 <4> Here we inject the JAX-RS SecurityContext to inspect the security state of the call and use a `getResponseString()` function to populate a response string.
-<5> Here we check if the call is insecured by checking the request user/caller `Principal` against null.
+<5> Here we check if the call is insecure by checking the request user/caller `Principal` against null.
 <6> Here we check that the Principal and JsonWebToken have the same name since JsonWebToken does represent the current Principal.
 <7> Here we get the Principal name.
 <8> The reply we build up makes use of the caller name, the `isSecure()` and `getAuthenticationScheme()` states of the request `SecurityContext`, and whether a non-null `JsonWebToken` was injected.

docs/src/main/asciidoc/security-openid-connect-client.adoc

@@ -139,7 +139,7 @@ Alternatively, `OidcClientRequestFilter` can be registered automatically with al
 
 `quarkus-oidc-client-reactive-filter` extension provides `io.quarkus.oidc.client.filter.OidcClientRequestReactiveFilter`.
 
-It works similary to the way `OidcClientRequestFilter` (described in the previous section) does - it uses `OidcClient` to acquire the access token, refresh it if needed, and set it as an HTTP `Authorization` `Bearer` scheme value. The difference is that it works with link:rest-client-reactive[Reactive RestClient] and implements a non-blocking client filter which does not block the current IO thread when acquring or refreshing the tokens.
+It works similarly to the way `OidcClientRequestFilter` (described in the previous section) does - it uses `OidcClient` to acquire the access token, refresh it if needed, and set it as an HTTP `Authorization` `Bearer` scheme value. The difference is that it works with link:rest-client-reactive[Reactive RestClient] and implements a non-blocking client filter which does not block the current IO thread when acquiring or refreshing the tokens.
 
 `OidcClientRequestReactiveFilter` delays an initial token acquisition until it is executed to avoid blocking an IO thread and it currently can only be registered with `org.eclipse.microprofile.rest.client.annotation.RegisterProvider` annotation:
 
@@ -411,7 +411,7 @@ or with the secret retrieved from a link:credentials-provider[CredentialsProvide
 quarkus.oidc-client.auth-server-url=http://localhost:8180/auth/realms/quarkus/
 quarkus.oidc-client.client-id=quarkus-app
 
-# This is a key which will be used to retrieve a secret from the map of credentails returned from CredentialsProvider
+# This is a key which will be used to retrieve a secret from the map of credentials returned from CredentialsProvider
 quarkus.oidc-client.credentials.jwt.secret-provider.key=mysecret-key
 # Set it only if more than one CredentialsProvider can be registered
 quarkus.oidc-client.credentials.jwt.secret-provider.name=oidc-credentials-provider
@@ -671,7 +671,7 @@ Note `AccessTokenRequestFilter` will use `OidcClient` to exchange the current to
 
 Using `JsonWebTokenRequestFilter` is recommended if you work with Bearer JWT tokens where these tokens can have their claims such as `issuer` and `audience` modified and the updated tokens secured (for example, re-signed) again. It expects an injected `org.eclipse.microprofile.jwt.JsonWebToken` and therefore will not work with the opaque tokens. Also, if your OpenId Connect Provider supports a Token Exchange protocol then it is recommended to use `AccessTokenRequestFilter` instead - as both JWT and opaque bearer tokens can be securely exchanged with `AccessTokenRequestFilter`.
 
-`JsonWebTokenRequestFilter` makes it easy for `Service A` implemementations to update the injected `org.eclipse.microprofile.jwt.JsonWebToken` with the new `issuer` and `audience` claim values and secure the updated token again with a new signature. The only difficult step is to ensure `Service A` has a signing key - it should be provisioned from a secure file system or from the remote secure storage such as Vault.
+`JsonWebTokenRequestFilter` makes it easy for `Service A` implementations to update the injected `org.eclipse.microprofile.jwt.JsonWebToken` with the new `issuer` and `audience` claim values and secure the updated token again with a new signature. The only difficult step is to ensure `Service A` has a signing key - it should be provisioned from a secure file system or from the remote secure storage such as Vault.
 
 You can selectively register `JsonWebTokenRequestFilter` by using either `io.quarkus.oidc.token.propagation.JsonWebToken` or `org.eclipse.microprofile.rest.client.annotation.RegisterProvider`, for example:
 

docs/src/main/asciidoc/security-openid-connect-dev-services.adoc

@@ -38,7 +38,7 @@ $ mvn quarkus:dev
 
 The `quay.io/keycloak/keycloak:14.0.0` Keycloak image is used by default to start a container. `quarkus.keycloak.devservices.image-name` can be used to change the Keycloak image used.
 
-Note that by default, `Dev Services for Keycloak` will not start a new container if it finds a container with a `quarkus-dev-service-keycloak` label and connect to it if this label's value matches the value of the `quarkus.keycloak.devservces.service-name` property (default value is `quarkus`). In such cases you will see a slighty different output:
+Note that by default, `Dev Services for Keycloak` will not start a new container if it finds a container with a `quarkus-dev-service-keycloak` label and connect to it if this label's value matches the value of the `quarkus.keycloak.devservices.service-name` property (default value is `quarkus`). In such cases you will see a slighty different output:
 
 [source,shell]
 ----
@@ -64,7 +64,7 @@ By default the Keycloak page can be used to support the development of a link:se
 [[keycloak-authorization-code-grant]]
 ==== Authorization Code Grant
 
-If you set `quarkus.keycloak.devservices.grant.type=code` in `applicatin.properties` (this is a default value) then an `authorization_code` grant will be used to acquire both access and ID tokens. Using this grant is recommended to emulate a typical flow where a `Single Page Application` acquires the tokens and uses them to access Quarkus services.
+If you set `quarkus.keycloak.devservices.grant.type=code` in `application.properties` (this is a default value) then an `authorization_code` grant will be used to acquire both access and ID tokens. Using this grant is recommended to emulate a typical flow where a `Single Page Application` acquires the tokens and uses them to access Quarkus services.
 
 First you will see an option to `Log into Single Page Application`:
 
@@ -112,11 +112,11 @@ You can set the `redirect_uri` value to `*` only for the test purposes, especial
 
 ==== Implicit Grant
 
-If you set `quarkus.keycloak.devservices.grant.type=implicit` in `applicatin.properties` then an `implicit` grant will be used to acquire both access and ID tokens. Use this grant for emulating a `Single Page Application` only if the authorization code grant does not work (for example, a client is configured in Keycloak to support an implicit grant, etc).
+If you set `quarkus.keycloak.devservices.grant.type=implicit` in `application.properties` then an `implicit` grant will be used to acquire both access and ID tokens. Use this grant for emulating a `Single Page Application` only if the authorization code grant does not work (for example, a client is configured in Keycloak to support an implicit grant, etc).
 
 ==== Password Grant
 
-If you set `quarkus.keycloak.devservices.grant.type=password` in `applicatin.properties` then you will see a screen like this one:
+If you set `quarkus.keycloak.devservices.grant.type=password` in `application.properties` then you will see a screen like this one:
 
 image::dev-ui-keycloak-password-grant.png[alt=Dev UI OpenId Connect Keycloak Page - Password Grant,role="center"]
 
@@ -183,7 +183,7 @@ Note that even if you initialize Keycloak from a realm file, it is still needed
 
 == Disable Dev Services for Keycloak
 
-`Dev Services For Keycloak` will not be activated if either `quarkus.oidc.auth-server-url` is already initialized or the defaut OIDC tenant is disabled with `quarkus.oidc.tenant.enabled=false`, irrespectively of whether you work with Keycloak or not.
+`Dev Services For Keycloak` will not be activated if either `quarkus.oidc.auth-server-url` is already initialized or the default OIDC tenant is disabled with `quarkus.oidc.tenant.enabled=false`, irrespectively of whether you work with Keycloak or not.
 
 If you prefer not to have a `Dev Services for Keycloak` container started or do not work with Keycloak then you can also disable this feature with `quarkus.keycloak.devservices.enabled=false` - it will only be necessary if you expect to start `quarkus:dev` without `quarkus.oidc.auth-server-url`.
 
@@ -216,7 +216,7 @@ image::dev-ui-oidc-devconsole-card.png[alt=Generic Dev UI OpenId Connect Card,ro
 
 Follow the link and you'll be able log in to your provider, get the tokens and test the application. The experience will be the same as described in the <<keycloak-authorization-code-grant,Authorization Code Grant for Keycloak>> section, where `Dev Services for Keycloak` container has been started, especially if you work with Keycloak (please also pay attention to a `redirect_uri` note in that section).
 
-If you work with other providers then a Dev UI experience described in the <<keycloak-authorization-code-grant,Authorization Code Grant for Keycloak>> section might differ slightly. For example, an access token may not be in a JWT format so it won't be possibe to show its internal content, though all providers should return an ID Token as JWT.
+If you work with other providers then a Dev UI experience described in the <<keycloak-authorization-code-grant,Authorization Code Grant for Keycloak>> section might differ slightly. For example, an access token may not be in a JWT format so it won't be possible to show its internal content, though all providers should return an ID Token as JWT.
 
 Some providers such as `Auth0` do not support a standard RP initiated logout so a logout option will also be hidden.