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
the key prefix allowing to identify the keys belonging to the cache. If not set, use "cache:$cache-name"
77444
+
The key prefix allowing to identify the keys belonging to the cache. If not set, the value "`cache:++{++cache-name`++}++" will be used. The variable "`++{++cache-name`++}++" is resolved from the value set in the cache annotations.
the key prefix allowing to identify the keys belonging to the cache. If not set, use "cache:$cache-name"
77574
+
The key prefix allowing to identify the keys belonging to the cache. If not set, the value "`cache:++{++cache-name`++}++" will be used. The variable "`++{++cache-name`++}++" is resolved from the value set in the cache annotations.
If set to `true`, then this REST Client will not the default exception mapper which always throws an exception if HTTP response code >= 400. This property is not applicable to the RESTEasy Client.
the key prefix allowing to identify the keys belonging to the cache. If not set, use "cache:$cache-name"
123
+
The key prefix allowing to identify the keys belonging to the cache. If not set, the value "`cache:++{++cache-name`++}++" will be used. The variable "`++{++cache-name`++}++" is resolved from the value set in the cache annotations.
the key prefix allowing to identify the keys belonging to the cache. If not set, use "cache:$cache-name"
253
+
The key prefix allowing to identify the keys belonging to the cache. If not set, the value "`cache:++{++cache-name`++}++" will be used. The variable "`++{++cache-name`++}++" is resolved from the value set in the cache annotations.
the key prefix allowing to identify the keys belonging to the cache. If not set, use "cache:$cache-name"
123
+
The key prefix allowing to identify the keys belonging to the cache. If not set, the value "`cache:++{++cache-name`++}++" will be used. The variable "`++{++cache-name`++}++" is resolved from the value set in the cache annotations.
the key prefix allowing to identify the keys belonging to the cache. If not set, use "cache:$cache-name"
253
+
The key prefix allowing to identify the keys belonging to the cache. If not set, the value "`cache:++{++cache-name`++}++" will be used. The variable "`++{++cache-name`++}++" is resolved from the value set in the cache annotations.
If set to `true`, then this REST Client will not the default exception mapper which always throws an exception if HTTP response code >= 400. This property is not applicable to the RESTEasy Client.
If set to `true`, then this REST Client will not the default exception mapper which always throws an exception if HTTP response code >= 400. This property is not applicable to the RESTEasy Client.
When using Redis as the backend for Quarkus cache, each cached item will be stored in Redis:
22
22
23
23
- The backend uses the _<default>_ Redis client (if not configured otherwise), so make sure it's configured (or use the xref:redis-dev-services.adoc[Redis Dev Service])
24
-
- the Redis key is built as follows: `cache:$cache-name:$cache-key`, where `cache-key` is the key the application uses.
24
+
- the Redis key is built as follows: `cache:{cache-name}:{cache-key}`, where `cache-key` is the key the application uses and `cache:{cache-name}` the prefix.
By default, the Redis backend stores the entry using the following keys: `cache:$cache-name:$cache-key`, where `cache-key` is the key the application uses.
122
-
So, you can find all the entries for a single cache using the Redis `KEYS` command: `KEYS cache:$cache-name:*`
121
+
By default, the Redis backend stores the entry using the following keys pattern: `cache:{cache-name}:{cache-key}`, where `cache-key` is the key the application uses and `cache:{cache-name}` the prefix. The variable `{cache-name}` is resolved from the value set in the cache annotations.
122
+
So, you can find all the entries for a single cache using the Redis `KEYS` command: `KEYS cache:{cache-name}:*`
123
+
124
+
The prefix can be configured by using the `prefix` property:
123
125
124
-
The `cache:$cache-name:` segment can be configured using the `prefix` property:
In these cases, you can find all the keys managed by the default cache using `KEYS my-cache:*`, and all the keys managed by the `expensiveResourceCache` cache using: `KEYS my-expensive-cache:*`.
137
138
139
+
140
+
----
141
+
# Default configuration
142
+
# The variable "{cache-name}" is resolved from the value set in the cache annotations.
143
+
quarkus.cache.redis.prefix=my-cache-{cache-name}
144
+
----
145
+
146
+
In this latest example, you can find all the keys managed by the default cache using `KEYS my-cache-{cache-name}:*`.
147
+
148
+
138
149
== Enable optimistic locking
139
150
140
151
The access to the cache can be _direct_ or use https://redis.io/docs/manual/transactions/#optimistic-locking-using-check-and-set[optimistic locking].
Copy file name to clipboardExpand all lines: _versions/main/guides/datasource.adoc
+4-5Lines changed: 4 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -259,12 +259,11 @@ For more information about configuring JDBC, see <<jdbc-url,JDBC URL format refe
259
259
[[other-databases]]
260
260
===== Custom databases and drivers
261
261
262
-
If you need to connect to a database for which Quarkus does not provide an extension with the JDBC driver,
263
-
you can use a custom driver instead. For example, if you are using the OpenTelemetry JDBC driver in your project.
262
+
If Quarkus does not provide a JDBC extension for your database, or you need to use a different JDBC driver, such as one for OpenTelemetry, you can configure the JDBC driver explicitly.
264
263
265
-
Without an extension, the driver will work correctly in any Quarkus app running in JVM mode.
266
-
However, the driver is unlikely to work when compiling your application to a native executable.
267
-
If you plan to make a native executable, use the existing JDBC Quarkus extensions, or contribute one for your driver.
264
+
Without an extension, JDBC drivers are expected to work correctly in JVM mode.
265
+
However, they are unlikely to function when compiling your application into a native executable.
266
+
To build a native executable, use an existing Quarkus JDBC extension or contribute a new extension for your driver.
268
267
269
268
.An example for defining access to a database with no built-in support in JVM mode:
Copy file name to clipboardExpand all lines: _versions/main/guides/logging.adoc
+14-10Lines changed: 14 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -115,21 +115,25 @@ The fully qualified name of the class that calls the `Log` methods is used as a
115
115
In this example, the logger name would be `com.example.MyService`.
116
116
<3> Finally, all calls to `Log` methods are rewritten to regular JBoss Logging calls on the logger field during the application build.
117
117
118
-
WARNING: Only use the `Log` API in application classes, not in external dependencies.
119
-
`Log` method calls that are not processed by Quarkus at build time will throw an exception.
120
-
121
118
[[log-api-extension-warning]]
122
-
==== Important Note on Using `io.quarkus.logging.Log` in Extensions
119
+
[WARNING]
120
+
====
121
+
Use the `Log` API only in application classes, not in external dependencies.
122
+
`Log` method calls not processed by Quarkus at build time will result in an exception.
123
123
124
-
While the `Log` API simplifies logging in application classes, it should not be used in extension modules or external dependencies. The following considerations apply:
124
+
.Using `io.quarkus.logging.Log` in extensions:
125
125
126
-
* `io.quarkus.logging.Log` depends on Quarkus bytecode transformations that occur at build time.
127
-
* In extension modules, the use of `Log` may work if the module has a Jandex index. However, this behavior is not officially supported and might lead to unreliable logging.
126
+
While the `Log` API simplifies logging in application classes, it is not recommended for use in extension modules or external dependencies.
128
127
129
-
For extension development:
128
+
The following considerations apply:
130
129
131
-
* Use standard loggers like `org.jboss.logging.Logger.getLogger(String)` instead of `io.quarkus.logging.Log`.
132
-
* This avoids potential performance issues caused by the stack walk fallback when Quarkus build-time processing is unavailable.
130
+
* `io.quarkus.logging.Log` depends on Quarkus bytecode transformations that occur at build time.
131
+
132
+
* In extension modules, `Log` works only if the module includes a Jandex index.
133
+
However, this behavior is unsupported and can lead to unreliable logging.
134
+
+
135
+
For extension development, use `org.jboss.logging.Logger.getLogger(String)` instead of `io.quarkus.logging.Log`.
0 commit comments