You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
H2 and Derby databases can be configured to run in "embedded mode"; however, the Derby extension does not support compiling the embedded database engine into native executables.
204
+
You can configure H2 and Derby databases to run in "embedded mode"; however, the Derby extension does not support compiling the embedded database engine into native executables.
205
205
206
-
Read <<in-memory-databases,Testing with in-memory databases>> for suggestions regarding integration testing.
206
+
For suggestions regarding integration testing, see <<in-memory-databases,Testing with in-memory databases>> .
207
207
====
208
208
* DB2 - `quarkus-jdbc-db2`
209
209
* MariaDB - `quarkus-jdbc-mariadb`
@@ -225,10 +225,9 @@ For example, to add the PostgreSQL driver dependency:
225
225
[NOTE]
226
226
====
227
227
Using a built-in JDBC driver extension automatically includes the Agroal extension, which is the JDBC connection pool implementation applicable for custom and built-in JDBC drivers.
228
-
However, for custom drivers, Agroal needs to be added explicitly.
228
+
However, for custom drivers, you must add Agroal explicitly.
229
229
====
230
230
231
-
232
231
.. For use with a custom JDBC driver, add the `quarkus-agroal` dependency to your project alongside the extension for your relational database driver:
For all the details about the JDBC configuration options and configuring other aspects,
280
-
such as the connection pool size, refer to the <<jdbc-configuration,JDBC configuration reference>> section.
278
+
For details about JDBC configuration options and configuring other aspects, such as the connection pool size, refer to the <<jdbc-configuration,JDBC configuration reference>> section.
281
279
282
280
===== Consuming the datasource
283
281
@@ -303,7 +301,7 @@ Because this behavior is unexpected and can lead to data loss, an interceptor ro
303
301
However, if you use XA transactions, the transaction manager handles the rollback.
304
302
305
303
If the behavior introduced in 3.18 causes issues for your workload, disable it by setting the `-Dquarkus-oracle-no-automatic-rollback-on-connection-close` system property to `true`.
306
-
Make sure to report your use case in our link:https://github.com/quarkusio/quarkus/issues[issue tracker] so we can adjust this behavior if needed, for example, with more permanent settings.
304
+
Make sure to report your use case in the link:https://github.com/quarkusio/quarkus/issues[issue tracker] so we can adjust this behavior if needed, for example, with more permanent settings.
307
305
308
306
309
307
[[reactive-datasource]]
@@ -680,11 +678,12 @@ You can override this by setting the `transactions` configuration property:
680
678
* `quarkus.datasource.jdbc.transactions` for default unnamed datasource
681
679
* `quarkus.datasource._<datasource-name>_.jdbc.transactions` for named datasource
682
680
683
-
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`/`quarkus.datasource."datasource-name".jdbc.enable-recovery` to `false`. Only use this for advanced use cases and if you know recovery will not be necessary, otherwise it may result in data loss and/or data unavailability because resources may become locked indefinitely.
681
+
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.
682
+
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`.
683
+
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.
684
684
685
685
For more information, see the <<configuration-reference,Configuration reference>> section below.
686
-
687
-
To facilitate the storage of transaction logs in a database by using JDBC, see xref:transaction.adoc#jdbcstore[Configuring transaction logs to be stored in a datasource] section of the xref:transaction.adoc[Using transactions in Quarkus] guide.
686
+
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.
Copy file name to clipboardExpand all lines: _guides/gradle-tooling.adoc
+11Lines changed: 11 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -923,3 +923,14 @@ The current state of compatibility is shown in the following table:
923
923
|`addExtension`|❌
924
924
|`removeExtension`|❌
925
925
|====
926
+
927
+
== Dependency resolver options
928
+
929
+
=== Quarkus component variants
930
+
931
+
`disableQuarkusComponentVariants` project property was introduced in Quarkus 3.25.1 to control whether Quarkus component variants should be added to certain dependencies of a project to enable xref:conditional-extension-dependencies.adoc[Quarkus conditional] and build time (deployment) dependencies. Quarkus component variants are enabled by default since 3.25.1.
932
+
933
+
The approach to enable Quarkus conditional and extension build time (deployment) dependencies has changed in Quarkus 3.25.1 due to a few issues with the previous implementation.
934
+
Specifically, the previous implementation would not apply relevant dependency exclusions to enabled conditional and deployment dependencies. It would also appear to leak devmode-only dependencies into non-devmode classpaths (such as test and prod) in some cases. These issues couldn't be fixed in a reasonable way in the previous implementation, which is why the Quarkus dependency resolution had to be re-implemented based on a different approach using link:https://docs.gradle.org/current/userguide/variant_aware_resolution.html[Gradle component variants].
935
+
936
+
The previous implementation still remains available for now in case the new one appears to introduce not yet detected regressions and can be enabled by setting `disableQuarkusComponentVariants` project property to `true`.
Copy file name to clipboardExpand all lines: _guides/logging.adoc
+7-3Lines changed: 7 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -143,9 +143,13 @@ For extension development, use `org.jboss.logging.Logger.getLogger(String)` inst
143
143
144
144
The injection of a configured `org.jboss.logging.Logger` logger instance with the `@Inject` annotation is another alternative to adding an application logger, but is applicable only to CDI beans.
145
145
146
-
You can use `@Inject Logger log`, where the logger gets named after the class you inject it to, or `@LoggerName("...") Logger log`, where the logger will receive the specified name. Notice, that `@Inject`
147
-
is not required if you already annotated your `Logger` with `@LoggerName("...")`.
148
-
146
+
You can use `@Inject Logger log`, where the logger gets named after the class you inject it to, or `@LoggerName("...") Logger log`, where the logger receives the specified name.
147
+
148
+
[NOTE]
149
+
====
150
+
`@Inject` is not required if you already annotated your `Logger` with `@LoggerName("...")`.
151
+
====
152
+
149
153
Once injected, you can use the `log` object to invoke logging methods.
150
154
151
155
.An example of two different types of logger injection:
Copy file name to clipboardExpand all lines: _guides/security-jwt-build.adoc
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -370,7 +370,7 @@ SmallRye JWT supports the following properties, which can be used to customize h
370
370
|`smallrye.jwt.new-token.issuer` |none |Token issuer used to set an `iss` (issuer) claim value if this claim has not already been set.
371
371
|`smallrye.jwt.new-token.audience` |none |Token audience used to set an `aud` (audience) claim value if this claim has not already been set.
372
372
|`smallrye.jwt.new-token.override-matching-claims` |`false` | Set this property to `true` for `smallrye.jwt.new-token.issuer` and `smallrye.jwt.new-token.audience` values to override the already initialized `iss` (issuer) and `aud` (audience) claims.
373
-
|smallrye.jwt.new-token.add-default-claims|true|Set this property to `false` to disable an automatic addition of the `iat` (issued at), `exp` (expiration time) and `jti` (token identifier) claims when such claims have not already been set.
373
+
|`smallrye.jwt.new-token.add-default-claims`|true|Set this property to `false` to disable an automatic addition of the `iat` (issued at), `exp` (expiration time) and `jti` (token identifier) claims when such claims have not already been set.
374
374
|`smallrye.jwt.keystore.type` |`JKS` |This property can be used to customize a keystore type if either `smallrye.jwt.sign.key.location` or `smallrye.jwt.encrypt.key.location` or both of these properties point to a `KeyStore` file. If it is not set then the file name will be checked to determine the keystore type before defaulting to `JKS`.
375
375
|`smallrye.jwt.keystore.provider` | |This property can be used to customize a `KeyStore` provider if `smallrye.jwt.sign.key.location` or `smallrye.jwt.encrypt.key.location` point to a `KeyStore` file.
376
376
|`smallrye.jwt.keystore.password` | |Keystore password. If `smallrye.jwt.sign.key.location` or `smallrye.jwt.encrypt.key.location` point to a `KeyStore` file, this property must be set.
The link:https://smallrye.io/docs/smallrye-fault-tolerance/6.9.1/reference/programmatic-api.html[programmatic API] is present and integrated with the declarative, annotation-based API.
611
+
The link:https://smallrye.io/docs/smallrye-fault-tolerance/6.9.2/reference/programmatic-api.html[programmatic API] is present and integrated with the declarative, annotation-based API.
612
612
You can use the `Guard`, `TypedGuard` and `@ApplyGuard` APIs out of the box.
613
613
614
614
Support for Kotlin is present (assuming you use the Quarkus extension for Kotlin), so you can guard your `suspend` functions with fault tolerance annotations.
Copy file name to clipboardExpand all lines: _guides/tls-registry-reference.adoc
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -57,8 +57,8 @@ For instance, `quarkus.tls.reload-period` will only be applied to the default TL
57
57
58
58
[IMPORTANT]
59
59
====
60
-
As described in detail link:https://github.com/quarkusio/quarkus/blob/main/adr/0004-using-the-tls-registry-for-clients.adoc#configuring-clients-with-the-tls-registry[here], Quarkus client extensions (REST, GRPC, etc) ignore properties, defined in default (ie unnamed) TLS configuration.
61
-
The only exception is `quarkus.tls.trust-all` property.
60
+
As described in detail link:https://github.com/quarkusio/quarkus/blob/main/adr/0004-using-the-tls-registry-for-clients.adoc#configuring-clients-with-the-tls-registry[here], Quarkus client extensions (such as REST, GRPC, and so on) ignore properties defined in default (that is, unnamed) TLS configurations.
61
+
The `quarkus.tls.trust-all` property is the only exception.
62
62
====
63
63
64
64
=== Configuring HTTPS for a HTTP server
@@ -798,7 +798,7 @@ A value of `true` means the reload operation was successful, not necessarily tha
798
798
799
799
After a `TlsConfiguration` has been reloaded, servers and clients using this configuration may need to perform specific actions to apply the new certificates.
800
800
801
-
The recommended approach for informing clients and servers about the certificate reload is to fire a CDI event of type `io.quarkus.tls.CertificateUpdatedEvent`.
801
+
The preferred approach for informing clients and servers about the certificate reload is to fire a CDI event of type `io.quarkus.tls.CertificateUpdatedEvent`.
802
802
To do so, inject a CDI event of this type and fire it when a reload occurs.
803
803
804
804
.An example of manually reloading a TLS configuration and notifying components by firing a `CertificateUpdatedEvent` and reacting to it:
Impacted servers and clients may need to listen to the `CertificateUpdatedEvent` to apply the new certificates.
858
-
This is automatically done for the Quarkus HTTP server, as well as the Quarkus REST server, gRPC server, and WebSocket server, as well as the management interface if it is enabled.
857
+
Impacted servers and clients might need to listen to the `CertificateUpdatedEvent` to apply the new certificates.
858
+
This is automatically handled for the Quarkus HTTP, REST, gRPC, and WebSocket servers, as well as the management interface if enabled.
859
859
On the client side, Quarkus REST Client automatically handles certificate update events.
0 commit comments