The exception classes expected to be thrown by the handler. Any exception thrown by the handler that is an instance of a class in this list will not be logged, but will otherwise be handled normally by the lambda runtime. This is useful for avoiding unnecessary stack traces while preserving the ability to log unexpected exceptions.
The handler name. Handler names are specified on handler classes using the @jakarta.inject.Named annotation. If this name is unspecified and there is exactly one unnamed implementation of com.amazonaws.services.lambda.runtime.RequestHandler then this unnamed handler will be used. If there is only a single named handler and the name is unspecified then the named handler will be used.
Regular expression to locate role values within a Cognito claim string. By default it looks for space delimited strings enclosed in brackets "[^\[\] \t]+"
Whether we want to use regular JDBC transactions, XA, or disable all transactional capabilities.
When enabling XA you will need a driver implementing javax.sql.XADataSource.
The initial size of the pool. Usually you will want to set the initial size to match at least the minimal size, but this is not enforced so to allow for architectures which prefer a lazy initialization of the connections on boot, while being able to sustain a minimal pool size after boot.
When enabled Agroal will be able to produce a warning when a connection is returned to the pool without the application having closed all open statements. This is unrelated with tracking of open connections. Disable for peak performance, but only when there’s high confidence that no leaks are happening.
Require an active transaction when acquiring a connection. Recommended for production. WARNING: Some extensions acquire connections without holding a transaction for things like schema updates and schema validation. Setting this setting to STRICT may lead to failures in those cases.
Whether we want to use regular JDBC transactions, XA, or disable all transactional capabilities.
When enabling XA you will need a driver implementing javax.sql.XADataSource.
The initial size of the pool. Usually you will want to set the initial size to match at least the minimal size, but this is not enforced so to allow for architectures which prefer a lazy initialization of the connections on boot, while being able to sustain a minimal pool size after boot.
When enabled Agroal will be able to produce a warning when a connection is returned to the pool without the application having closed all open statements. This is unrelated with tracking of open connections. Disable for peak performance, but only when there’s high confidence that no leaks are happening.
Require an active transaction when acquiring a connection. Recommended for production. WARNING: Some extensions acquire connections without holding a transaction for things like schema updates and schema validation. Setting this setting to STRICT may lead to failures in those cases.
Whether a health check is published in case the smallrye-health extension is present.
If you enable the health check, you must specify the kafka.bootstrap.servers property.
Whether to enable Snappy in native mode.
Note that Snappy requires GraalVM 21+ and embeds a native library in the native executable. This library is unpacked and loaded when the application starts.
If Dev Services for Kafka has been explicitly enabled or disabled. Dev Services are generally enabled by default, unless there is an existing configuration present. For Kafka, Dev Services starts a broker unless kafka.bootstrap.servers is set or if all the Reactive Messaging Kafka channel are configured with a bootstrap.servers.
Indicates if the Kafka broker managed by Quarkus Dev Services is shared. When shared, Quarkus looks for running containers using label-based service discovery. If a matching container is found, it is used, and so a second one is not started. Otherwise, Dev Services for Kafka starts a new container.
The discovery uses the quarkus-dev-service-kafka label. The value is configured using the service-name property.
Container sharing is only used in dev mode.
The value of the quarkus-dev-service-kafka label attached to the started container. This property is used when shared is set to true. In this case, before starting a container, Dev Services for Kafka looks for a container with the quarkus-dev-service-kafka label set to the configured value. If found, it will use this container instead of starting a new one. Otherwise, it starts a new container with the quarkus-dev-service-kafka label set to the specified value.
This property is used when you need multiple shared Kafka brokers.
The topic-partition pairs to create in the Dev Services Kafka broker. After the broker is started, given topics with partitions are created, skipping already existing topics. For example, quarkus.kafka.devservices.topic-partitions.test=2 will create a topic named test with 2 partitions.
The topic creation will not try to re-partition existing topics with different number of partitions.
A comma-separated list of host:port pairs identifying the Kafka bootstrap server(s). If not set, fallback to kafka.bootstrap.servers, and if not set either use localhost:9012.
A comma-separated list of topic names. The pipeline will only be started once all these topics are present in the Kafka cluster and ignore.topics is set to false.
The schema registry key. Different schema registry libraries expect a registry URL in different configuration properties. For Apicurio Registry, use apicurio.registry.url. For Confluent schema registry, use schema.registry.url.
If set to true @Inject is automatically added to all non-static non-final fields that are annotated with one of the annotations defined by AutoInjectAnnotationBuildItem.
If set to true, the bytecode of unproxyable beans will be transformed. This ensures that a proxy/subclass can be created properly. If the value is set to false, then an exception is thrown at build time indicating that a subclass/proxy could not be created. Quarkus performs the following transformations when this setting is enabled:
- Remove 'final' modifier from classes and methods when a proxy is required.
- Create a no-args constructor if needed.
- Makes private no-args constructors package-private if necessary.
If set to true, the bytecode of private fields that are injection points will be transformed to package private. This ensures that field injection can be performed completely reflection-free. If the value is set to false, then a reflection fallback is used to perform the injection.
If set to true (the default), the build fails if a private method that is neither an observer nor a producer, is annotated with an interceptor binding. An example of this is the use of Transactional on a private method of a bean. If set to false, Quarkus simply logs a warning that the annotation will be ignored.
The list of selected alternatives for an application.
An element value can be:
- a fully qualified class name, i.e. org.acme.Foo
- a simple class name as defined by Class#getSimpleName(), i.e. Foo
- a package name with suffix .*, i.e. org.acme.*, matches a package
- a package name with suffix .**, i.e. org.acme.**, matches a package that starts with the value Each element value is used to match an alternative bean class, an alternative stereotype annotation type or a bean class that declares an alternative producer. If any value matches then the priority of Integer#MAX_VALUE is used for the relevant bean. The priority declared via jakarta.annotation.Priority is overridden.
If set to true then jakarta.enterprise.inject.Produces is automatically added to all non-void methods that are annotated with a scope annotation, a stereotype or a qualifier, and are not annotated with Inject or Produces, and no parameter is annotated with Disposes, Observes or ObservesAsync.
The list of types that should be excluded from discovery.
An element value can be:
- a fully qualified class name, i.e. org.acme.Foo
- a simple class name as defined by Class#getSimpleName(), i.e. Foo
- a package name with suffix .*, i.e. org.acme.*, matches a package
- a package name with suffix .**, i.e. org.acme.**, matches a package that starts with the value If any element value matches a discovered type then the type is excluded from discovery, i.e. no beans and observer methods are created from this type.
List of types that should be considered unremovable regardless of whether they are directly used or not. This is a configuration option equivalent to using io.quarkus.arc.Unremovable annotation.
An element value can be:
- a fully qualified class name, i.e. org.acme.Foo
- a simple class name as defined by Class#getSimpleName(), i.e. Foo
- a package name with suffix .*, i.e. org.acme.*, matches a package
- a package name with suffix .**, i.e. org.acme.**, matches a package that starts with the value If any element value matches a discovered bean, then such a bean is considered unremovable.
If set to true then the container attempts to detect "unused removed beans" false positives during programmatic lookup at runtime. You can disable this feature to conserve some memory when running your application in production.
If set to true then the container attempts to detect wrong usages of annotations and eventually fails the build to prevent unexpected behavior of a Quarkus application.
A typical example is @jakarta.ejb.Singleton which is often confused with @jakarta.inject.Singleton. As a result a component annotated with @jakarta.ejb.Singleton would be completely ignored. Another example is an inner class annotated with a scope annotation - this component would be again completely ignored.
If set to true, the container will perform additional validations mandated by the CDI specification. Some improvements on top of the CDI specification may be disabled. Applications that work as expected in the strict mode should work without a change in the default, non-strict mode.
The strict mode is mainly introduced to allow passing the CDI Lite TCK. Applications are recommended to use the default, non-strict mode, which makes CDI more convenient to use. The "strictness" of the strict mode (the set of additional validations and the set of disabled improvements on top of the CDI specification) may change over time.
Note that transform-unproxyable-classes and remove-unused-beans also has effect on specification compatibility. You may want to disable these features to get behavior closer to the specification.
The list of packages that will not be checked for split package issues.
A package string representation can be:
- a full name of the package, i.e. org.acme.foo
- a package name with suffix .*, i.e. org.acme.*, which matches a package that starts with provided value
Minimum total size for the internal data structures. Providing a large enough estimate at construction time avoids the need for expensive resizing operations later, but setting this value unnecessarily high wastes memory.
Maximum number of entries the cache may contain. Note that the cache may evict an entry before this limit is exceeded or temporarily exceed the threshold while evicting. As the cache size grows close to the maximum, the cache evicts entries that are less likely to be used again. For example, the cache may evict an entry because it hasn’t been used recently or very often.
Specifies that each entry should be automatically removed from the cache once a fixed duration has elapsed after the entry’s creation, or the most recent replacement of its value.
Specifies that each entry should be automatically removed from the cache once a fixed duration has elapsed after the entry’s creation, the most recent replacement of its value, or its last read.
Whether or not metrics are recorded if the application depends on the Micrometer extension. Setting this value to true will enable the accumulation of cache stats inside Caffeine.
Minimum total size for the internal data structures. Providing a large enough estimate at construction time avoids the need for expensive resizing operations later, but setting this value unnecessarily high wastes memory.
Maximum number of entries the cache may contain. Note that the cache may evict an entry before this limit is exceeded or temporarily exceed the threshold while evicting. As the cache size grows close to the maximum, the cache evicts entries that are less likely to be used again. For example, the cache may evict an entry because it hasn’t been used recently or very often.
Specifies that each entry should be automatically removed from the cache once a fixed duration has elapsed after the entry’s creation, or the most recent replacement of its value.
Specifies that each entry should be automatically removed from the cache once a fixed duration has elapsed after the entry’s creation, the most recent replacement of its value, or its last read.
Whether or not metrics are recorded if the application depends on the Micrometer extension. Setting this value to true will enable the accumulation of cache stats inside Caffeine.
DOCKER_HOST value to use. If not set, the env var DOCKER_HOST is used, if that is not set the value `unix:///var/run/docker.sock' (or 'npipe:///./pipe/docker_engine' for windows) is used.
Path to the JVM Dockerfile. If set to an absolute path then the absolute path will be used, otherwise the path will be considered relative to the project root. If not set src/main/docker/Dockerfile.jvm will be used.
Path to the native Dockerfile. If set to an absolute path then the absolute path will be used, otherwise the path will be considered relative to the project root. If not set src/main/docker/Dockerfile.native will be used.
The base image to be used when a container image is being produced for the jar build. When the application is built against Java 17 or higher, registry.access.redhat.com/ubi8/openjdk-17-runtime:1.15 is used as the default. Otherwise registry.access.redhat.com/ubi8/openjdk-11-runtime:1.15 is used as the default.
The base image to be used when a container image is being produced for the native binary build. The default is "quay.io/quarkus/quarkus-micro-image". You can also use "registry.access.redhat.com/ubi8/ubi-minimal" which is a bigger base image, but provide more built-in utilities such as the microdnf package manager.
If this is set, then it will be used as the entry point of the container image. There are a few things to be aware of when creating an entry point
- Entrypoint "INHERIT" means to inherit entrypoint from base image, jvmArguments field is used for arguments
- A valid entrypoint is jar package specific (see quarkus.package.type)
- A valid entrypoint depends on the location of both the launching scripts and the application jar file. To that end it’s helpful to remember that when fast-jar packaging is used (the default), all necessary application jars are added to the /work directory and that the same directory is also used as the working directory. When legacy-jar or uber-jar are used, the application jars are unpacked under the /app directory and that directory is used as the working directory.
- Even if the jvmArguments field is set, it is ignored completely unless entrypoint is "INHERIT" When this is not set, a proper default entrypoint will be constructed. As a final note, a very useful tool for inspecting container image layers that can greatly aid when debugging problems with endpoints is dive
If this is set, then it will be used as the entry point of the container image. There are a few things to be aware of when creating an entry point
- Entrypoint "INHERIT" means to inherit entrypoint from base image, nativeArguments field is used for arguments
- A valid entrypoint depends on the location of both the launching scripts and the native binary file. To that end it’s helpful to remember that the native application is added to the /work directory and that and the same directory is also used as the working directory
- Even if the nativeArguments field is set, it is ignored completely unless entrypoint is "INHERIT" When this is not set, a proper default entrypoint will be constructed. As a final note, a very useful tool for inspecting container image layers that can greatly aid when debugging problems with endpoints is dive
Controls the optimization which skips downloading base image layers that exist in a target registry. If the user does not set this property, then read as false. If true, base image layers are always pulled and cached. If false, base image layers will not be pulled/cached if they already exist on the target registry.
List of target platforms. Each platform is defined using the pattern: <os>|<arch>[/variant]|<os>/<arch>[/variant] for example: linux/amd64,linux/arm64/v8 If not specified, OS default is linux and architecture default is amd64. If more than one platform is configured, it is important to note that the base image has to be a Docker manifest or an OCI image index containing a version of each chosen platform. The feature does not work with native images, as cross-compilation is not supported. This configuration is based on an incubating feature of Jib. See Jib FAQ for more information.
The path of a file in which the digest of the generated image will be written. If the path is relative, the base path is the output directory of the build tool.
The path of a file in which the id of the generated image will be written. If the path is relative, the base path is the output directory of the build tool.
Whether to set the creation time to the actual build time. Otherwise, the creation time will be set to the Unix epoch (00:00:00, January 1st, 1970 in UTC). See Jib FAQ for more information
Whether to set the modification time (last modified time) of the files put by Jib in the image to the actual build time. Otherwise, the modification time will be set to the Unix epoch (00:00:00, January 1st, 1970 in UTC). If the modification time is constant (flag is set to false so Unix epoch is used) across two consecutive builds, the docker layer sha256 digest will be different only if the actual files added by Jib to the docker layer were changed. More exactly, having 2 consecutive builds will generate different docker layers only if the actual content of the files within the docker layer was changed. If the current timestamp is used the sha256 digest of the docker layer will always be different even if the content of the files didn’t change.
The base image to be used when a container image is being produced for the jar build. When the application is built against Java 17 or higher, registry.access.redhat.com/ubi8/openjdk-17:1.15 is used as the default. Otherwise registry.access.redhat.com/ubi8/openjdk-11:1.15 is used as the default.
The directory where the jar is added during the assemble phase. This is dependent on the S2I image and should be supplied if a non default image is used.
The directory where the native binary is added during the assemble phase. This is dependent on the S2I image and should be supplied if a non-default image is used.
The resulting filename of the native binary in the S2I image. This option may be used if the selected S2I image uses a fixed name for the native binary.
The base image to be used when a container image is being produced for the jar build. When the application is built against Java 17 or higher, registry.access.redhat.com/ubi8/openjdk-17:1.15 is used as the default. Otherwise registry.access.redhat.com/ubi8/openjdk-11:1.15 is used as the default.
The directory where the jar is added during the assemble phase. This is dependent on the S2I image and should be supplied if a non default image is used.
The directory where the native binary is added during the assemble phase. This is dependent on the S2I image and should be supplied if a non-default image is used.
The resulting filename of the native binary in the S2I image. This option may be used if the selected S2I image uses a fixed name for the native binary.
The directory where the jar is added during the assemble phase. This is dependent on the S2I image and should be supplied if a non default image is used.
The directory where the native binary is added during the assemble phase. This is dependent on the S2I image and should be supplied if a non-default image is used.
The resulting filename of the native binary in the S2I image. This option may be used if the selected S2I image uses a fixed name for the native binary.
If enabled the CSRF cookie will have its 'secure' parameter set to 'true' when HTTP is used. It may be necessary when running behind an SSL terminating reverse proxy. The cookie will always be secure if HTTPS is used even if this property is set to false.
Create CSRF token only if the HTTP GET relative request path matches one of the paths configured with this property. Use a comma to separate multiple path values.
Verify CSRF token in the CSRF filter. If this property is enabled then the input stream will be read and cached by the CSRF filter to verify the token. If you prefer then you can disable this property and compare CSRF form and cookie parameters in the application code using JAX-RS jakarta.ws.rs.FormParam which refers to the form-field-name form property and jakarta.ws.rs.CookieParam which refers to the CsrfReactiveConfig#cookieName cookie. Note that even if the CSRF token verification in the CSRF filter is disabled, the filter will still perform checks to ensure the token is available, has the correct token-size in bytes and that the Content-Type HTTP header is either 'application/x-www-form-urlencoded' or 'multipart/form-data'.
Require that only 'application/x-www-form-urlencoded' or 'multipart/form-data' body is accepted for the token verification to proceed. Disable this property for the CSRF filter to avoid verifying the token for POST requests with other content types. This property is only effective if verify-token property is enabled.
The version of the database we will connect to (e.g. '10.0').
The version number set here should follow the same numbering scheme
as the string returned by java.sql.DatabaseMetaData#getDatabaseProductVersion()
for your database’s JDBC driver.
This numbering scheme may be different from the most popular one for your database;
for example Microsoft SQL Server 2016 would be version 13.
As a rule, the version set here should be as high as possible,
but must be lower than or equal to the version of any database your application will connect to.
A high version will allow better performance and using more features
(e.g. Hibernate ORM may generate more efficient SQL,
avoid workarounds and take advantage of more database features),
but if it is higher than the version of the database you want to connect to,
it may lead to runtime exceptions
(e.g. Hibernate ORM may generate invalid SQL that your database will reject).
Some extensions (like the Hibernate ORM extension)
will try to check this version against the actual database version on startup,
leading to a startup failure when the actual version is lower
or simply a warning in case the database cannot be reached.
The default for this property is specific to each extension;
the Hibernate ORM extension will default to the oldest version it supports.
If DevServices has been explicitly enabled or disabled. DevServices is generally enabled by default, unless there is an existing configuration present. When DevServices is enabled Quarkus will attempt to automatically configure and start a database when running in Dev or Test mode.
The container image name to use, for container based DevServices providers. If the provider is not container based (e.g. a H2 Database) then this has no effect.
The container start command to use, for container based DevServices providers. If the provider is not container based (e.g. a H2 Database) then this has no effect.
Path to a SQL script that will be loaded from the classpath and applied to the Dev Service database If the provider is not container based (e.g. an H2 or Derby Database) then this has no effect.
Whether this particular data source should be excluded from the health check if the general health check for data sources is enabled.
By default, the health check includes all configured data sources (if it is enabled).
Whether or not an health check is published in case the smallrye-health extension is present.
This is a global setting and is not specific to a datasource.
Whether or not datasource metrics are published in case a metrics extension is present.
This is a global setting and is not specific to a datasource.
NOTE: This is different from the "jdbc.enable-metrics" property that needs to be set on the JDBC datasource level to enable collection of metrics for that datasource.
The credentials provider bean name.
It is the @Named value of the credentials provider bean. It is used to discriminate if multiple CredentialsProvider beans are available.
For Vault it is: vault-credentials-provider. Not necessary if there is only one credentials provider available.
Generic properties that are passed for additional container configuration.
Properties defined here are database specific and are interpreted specifically in each database dev service implementation.
The volumes to be mapped to the container. The map key corresponds to the host location and the map value is the container location. If the host location starts with "classpath:", then the mapping will load the resource from the classpath with read-only permission. When using a file system location, the volume will be created with read-write permission, so the data in your file system might be wiped out or altered. If the provider is not container based (e.g. an H2 or Derby Database) then this has no effect.
The version of the database we will connect to (e.g. '10.0').
The version number set here should follow the same numbering scheme
as the string returned by java.sql.DatabaseMetaData#getDatabaseProductVersion()
for your database’s JDBC driver.
This numbering scheme may be different from the most popular one for your database;
for example Microsoft SQL Server 2016 would be version 13.
As a rule, the version set here should be as high as possible,
but must be lower than or equal to the version of any database your application will connect to.
A high version will allow better performance and using more features
(e.g. Hibernate ORM may generate more efficient SQL,
avoid workarounds and take advantage of more database features),
but if it is higher than the version of the database you want to connect to,
it may lead to runtime exceptions
(e.g. Hibernate ORM may generate invalid SQL that your database will reject).
Some extensions (like the Hibernate ORM extension)
will try to check this version against the actual database version on startup,
leading to a startup failure when the actual version is lower
or simply a warning in case the database cannot be reached.
The default for this property is specific to each extension;
the Hibernate ORM extension will default to the oldest version it supports.
If DevServices has been explicitly enabled or disabled. DevServices is generally enabled by default, unless there is an existing configuration present. When DevServices is enabled Quarkus will attempt to automatically configure and start a database when running in Dev or Test mode.
The container image name to use, for container based DevServices providers. If the provider is not container based (e.g. a H2 Database) then this has no effect.
Generic properties that are passed for additional container configuration.
Properties defined here are database specific and are interpreted specifically in each database dev service implementation.
The container start command to use, for container based DevServices providers. If the provider is not container based (e.g. a H2 Database) then this has no effect.
Path to a SQL script that will be loaded from the classpath and applied to the Dev Service database If the provider is not container based (e.g. an H2 or Derby Database) then this has no effect.
The volumes to be mapped to the container. The map key corresponds to the host location and the map value is the container location. If the host location starts with "classpath:", then the mapping will load the resource from the classpath with read-only permission. When using a file system location, the volume will be created with read-write permission, so the data in your file system might be wiped out or altered. If the provider is not container based (e.g. an H2 or Derby Database) then this has no effect.
Whether this particular data source should be excluded from the health check if the general health check for data sources is enabled.
By default, the health check includes all configured data sources (if it is enabled).
The credentials provider bean name.
It is the @Named value of the credentials provider bean. It is used to discriminate if multiple CredentialsProvider beans are available.
For Vault it is: vault-credentials-provider. Not necessary if there is only one credentials provider available.
The executor growth resistance. A resistance factor applied after the core pool is full; values applied here will cause that fraction of submissions to create new threads when no idle thread is available. A value of 0.0f implies that threads beyond the core size should be created as aggressively as threads within it; a value of 1.0f implies that threads beyond the core size should never be created.
Prefill thread pool when creating a new Executor. When io.vertx.core.spi.ExecutorServiceFactory#createExecutor is called, initialise with the number of defined threads at startup
The maximum amount of time in seconds that a successfully resolved address will be cached.
If not set explicitly, resolved addresses may be cached forever.
If basic auth should be enabled. If both basic and form auth is enabled then basic auth will be enabled in silent mode. If no authentication mechanisms are configured basic auth is the default.
The landing page to redirect to if there is no saved page to redirect back to. Redirect to landing page can be disabled by setting quarkus.http.auth.form.landing-page=.
How old a cookie can get before it will be replaced with a new cookie with an updated timeout, also referred to as "renewal-timeout". Note that smaller values will result in slightly more server load (as new encrypted cookies will be generated more often), however larger values affect the inactivity timeout as the timeout is set when a cookie is generated. For example if this is set to 10 minutes, and the inactivity timeout is 30m, if a users last request is when the cookie is 9m old then the actual timeout will happen 21m after the last request, as the timeout is only refreshed when a new cookie is generated. In other words no timeout is tracked on the server side; the timestamp is encoded and encrypted in the cookie itself, and it is decrypted and parsed with each request.
If this is true and credentials are present then a user will always be authenticated before the request progresses. If this is false then an attempt will only be made to authenticate the user if a permission check is performed or the current user is required for some other reason.
A common root path for non-application endpoints. Various extension-provided endpoints such as metrics, health,
and openapi are deployed under this path by default.
Relative path (Default, q) →
Non-application endpoints will be served from
${quarkus.http.root-path}/${quarkus.http.non-application-root-path}.
Absolute path (/q) →
Non-application endpoints will be served from the specified path.
${quarkus.http.root-path} → Setting this path to the same value as HTTP root path disables
this root path. All extension-provided endpoints will be served from ${quarkus.http.root-path}.
If the management interface is enabled, the root path for the endpoints exposed on the management interface
is configured using the quarkus.management.root-path property instead of this property.
If enabled then the response body is compressed if the Content-Type header is set and the value is a compressed media type as configured via compress-media-types. Note that the RESTEasy Reactive and Reactive Routes extensions also make it possible to enable/disable compression declaratively using the annotations io.quarkus.vertx.http.Compressed and io.quarkus.vertx.http.Uncompressed.
When enabled, vert.x will decompress the request’s body if it’s compressed. Note that the compression format (e.g., gzip) must be specified in the Content-Encoding header in the request.
The HTTP host In dev/test mode this defaults to localhost, in prod mode this defaults to 0.0.0.0 Defaulting to 0.0.0.0 makes it easier to deploy Quarkus to container, however it is not suitable for dev/test mode as other people on the network can connect to your development machine.
If insecure (i.e. http rather than https) requests are allowed. If this is enabled then http works as normal. redirect will still open the http port, but all requests will be redirected to the HTTPS port. disabled will prevent the HTTP port from opening at all.
If this is true (the default) then HTTP/2 will be enabled. Note that for browsers to be able to use it HTTPS must be enabled, and you must be running on JDK11 or above, as JDK8 does not support ALPN.
Origins allowed for CORS Comma separated list of valid URLs, e.g.: http://www.quarkus.io,http://localhost:3000 In case an entry of the list is surrounded by forward slashes, it is interpreted as a regular expression.
HTTP methods allowed for CORS Comma separated list of valid methods. ex: GET,PUT,POST The filter allows any method if this is not set. default: returns any requested method as valid
HTTP headers allowed for CORS Comma separated list of valid headers. ex: X-Custom,Content-Disposition The filter allows any header if this is not set. default: returns any requested header as valid
The Access-Control-Allow-Credentials header is used to tell the browsers to expose the response to front-end JavaScript code when the request’s credentials mode Request.credentials is “include”. The value of this header will default to true if quarkus.http.cors.origins property is set and there is a match with the precise Origin header and that header is not '*'.
The CredentialsProvider. If this property is configured then a matching 'CredentialsProvider' will be used to get the keystore, keystore key and truststore passwords unless these passwords have already been configured. Please note that using MicroProfile ConfigSource which is directly supported by Quarkus Configuration should be preferred unless using CredentialsProvider provides for some additional security and dynamism.
The credentials provider bean name.
It is the @Named value of the credentials provider bean. It is used to discriminate if multiple CredentialsProvider beans are available. It is recommended to set this property even if there is only one credentials provider currently available to ensure the same provider is always found in deployments where more than one provider may be available.
The list of path to server certificates private key file using the PEM format. Specifying multiple files require SNI to be enabled. The order of the key files must match the order of the certificates.
An optional parameter to specify a provider of the key store file. If not given, the provider is automatically detected based on the key store file type.
An optional parameter to select a specific key in the key store. When SNI is disabled, if the key store contains multiple keys and no alias is specified, the behavior is undefined.
An optional parameter to define the password for the key, in case it’s different from key-store-password If not given then it may be retrieved from CredentialsProvider.
An optional parameter to specify a provider of the trust store file. If not given, the provider is automatically detected based on the trust store file type.
Enables Server Name Indication (SNI), an TLS extension allowing the server to use multiple certificates. The client indicate the server name during the TLS handshake, allowing the server to select the right certificate.
The number if IO threads used to perform IO. This will be automatically set to a reasonable value based on the number of CPU cores if it is not provided. If this is set to a higher value than the number of Vert.x event loops then it will be capped at the number of event loops. In general this should be controlled by setting quarkus.vertx.event-loops-pool-size, this setting should only be used if you want to limit the number of HTTP io threads to a smaller number than the total number of IO threads.
Http connection read timeout for blocking IO. This is the maximum amount of time a thread will wait for data, before an IOException will be thrown and the connection closed.
Whether the files sent using multipart/form-data will be stored locally.
If true, they will be stored in quarkus.http.body-handler.uploads-directory and will be made available via io.vertx.ext.web.RoutingContext.fileUploads(). Otherwise, the files sent using multipart/form-data will not be stored locally, and io.vertx.ext.web.RoutingContext.fileUploads() will always return an empty collection. Note that even with this option being set to false, the multipart/form-data requests will be accepted.
The directory where the files sent using multipart/form-data should be stored.
Either an absolute path or a path relative to the current directory of the application process.
Whether the form attributes should be added to the request parameters.
If true, the form attributes will be added to the request parameters; otherwise the form parameters will not be added to the request parameters
Whether the uploaded files should be removed after serving the request.
If true the uploaded files stored in quarkus.http.body-handler.uploads-directory will be removed after handling the request. Otherwise, the files will be left there forever.
Whether the body buffer should pre-allocated based on the Content-Length header value.
If true the body buffer is pre-allocated according to the size read from the Content-Length header. Otherwise, the body buffer is pre-allocated to 1KB, and is resized dynamically
A comma-separated list of ContentType to indicate whether a given multipart field should be handled as a file part. You can use this setting to force HTTP-based extensions to parse a message part as a file based on its content type. For now, this setting only works when using RESTEasy Reactive.
The encryption key that is used to store persistent logins (e.g. for form auth). Logins are stored in a persistent cookie that is encrypted with AES-256 using a key derived from a SHA-256 hash of the key that is provided here. If no key is provided then an in-memory one will be generated, this will change on every restart though so it is not suitable for production environments. This must be more than 16 characters long for security reasons
If this is true then the request start time will be recorded to enable logging of total request time. This has a small performance penalty, so is disabled by default.
Provides a hint (optional) for the default content type of responses generated for the errors not handled by the application.
If the client requested a supported content-type in request headers (e.g. "Accept: application/json", "Accept: text/html"), Quarkus will use that content type.
Otherwise, it will default to the content type configured here.
If this is true then the address, scheme etc. will be set from headers forwarded by the proxy server, such as X-Forwarded-For. This should only be set if you are behind a proxy that sets these headers.
If this is true and proxy address forwarding is enabled then the standard Forwarded header will be used. In case the not standard X-Forwarded-For header is enabled and detected on HTTP requests, the standard header has the precedence. Activating this together with quarkus.http.proxy.allow-x-forwarded has security implications as clients can forge requests with a forwarded header that is not overwritten by the proxy. Therefore, proxies should strip unexpected X-Forwarded or X-Forwarded-* headers from the client.
If either this or allow-forwarded are true and proxy address forwarding is enabled then the not standard Forwarded header will be used. In case the standard Forwarded header is enabled and detected on HTTP requests, the standard header has the precedence. Activating this together with quarkus.http.proxy.allow-forwarded has security implications as clients can forge requests with a forwarded header that is not overwritten by the proxy. Therefore, proxies should strip unexpected X-Forwarded or X-Forwarded-* headers from the client.
Configure the list of trusted proxy addresses. Received Forwarded, X-Forwarded or X-Forwarded-* headers from any other proxy address will be ignored. The trusted proxy address should be specified as the IP address (IPv4 or IPv6), hostname or Classless Inter-Domain Routing (CIDR) notation. Please note that Quarkus needs to perform DNS lookup for all hostnames during the request. For that reason, using hostnames is not recommended. Examples of a socket address in the form of host or host:port:
- 127.0.0.1:8084
- [0:0:0:0:0:0:0:1]
- [0:0:0:0:0:0:0:1]:8084
- [::]
- localhost
- localhost:8084 Examples of a CIDR notation:
- ::/128
- ::/0
- 127.0.0.0/8 Please bear in mind that IPv4 CIDR won’t match request sent from the IPv6 address and the other way around.
The HTTP policy that this permission set is linked to. There are 3 built in policies: permit, deny and authenticated. Role based policies can be defined, and extensions can add their own policies.
The methods that this permission set applies to. If this is not set then they apply to all methods. Note that if a request matches any path from any permission set, but does not match the constraint due to the method not being listed then the request will be denied. Method specific permissions take precedence over matches that do not have any methods set. This means that for example if Quarkus is configured to allow GET and POST requests to /admin to and no other permissions are configured PUT requests to /admin will be denied.
The paths that this permission check applies to. If the path ends in /* then this is treated as a path prefix, otherwise it is treated as an exact match. Matches are done on a length basis, so the most specific path match takes precedence. If multiple permission sets match the same path then explicit methods matches take precedence over matches without methods set, otherwise the most restrictive permissions are applied.
Path specific authentication mechanism which must be used to authenticate a user. It needs to match HttpCredentialTransport authentication scheme such as 'basic', 'bearer', 'form', etc.
Permissions granted to the SecurityIdentity if this policy is applied successfully (the policy allows request to proceed) and the authenticated request has required role. For example, you can map permission perm1 with actions action1 and action2 to role admin by setting quarkus.http.auth.policy.role-policy1.permissions.admin=perm1:action1,perm1:action2 configuration property. Granted permissions are used for authorization with the @PermissionsAllowed annotation.
Permissions granted by this policy will be created with a java.security.Permission implementation specified by this configuration property. The permission class must declare exactly one constructor that accepts permission name (String) or permission name and actions (String, String[]).
Enables / Disables the usage of a separate interface/port to expose the management endpoints. If sets to true, the management endpoints will be exposed to a different HTTP server. This avoids exposing the management endpoints on a publicly available server.
If this is true and credentials are present then a user will always be authenticated before the request progresses. If this is false then an attempt will only be made to authenticate the user if a permission check is performed or the current user is required for some other reason.
A common root path for management endpoints. Various extension-provided management endpoints such as metrics and health are deployed under this path by default.
If responses should be compressed.
Note that this will attempt to compress all responses, to avoid compressing already compressed content (such as images) you need to set the following header:
Content-Encoding: identity
Which will tell vert.x not to compress the response.
When enabled, vert.x will decompress the request’s body if it’s compressed.
Note that the compression format (e.g., gzip) must be specified in the Content-Encoding header in the request.
The HTTP host Defaults to 0.0.0.0 Defaulting to 0.0.0.0 makes it easier to deploy Quarkus to container, however it is not suitable for dev/test mode as other people on the network can connect to your development machine.
The CredentialsProvider. If this property is configured then a matching 'CredentialsProvider' will be used to get the keystore, keystore key and truststore passwords unless these passwords have already been configured. Please note that using MicroProfile ConfigSource which is directly supported by Quarkus Configuration should be preferred unless using CredentialsProvider provides for some additional security and dynamism.
The credentials provider bean name.
It is the @Named value of the credentials provider bean. It is used to discriminate if multiple CredentialsProvider beans are available. It is recommended to set this property even if there is only one credentials provider currently available to ensure the same provider is always found in deployments where more than one provider may be available.
The list of path to server certificates private key file using the PEM format. Specifying multiple files require SNI to be enabled. The order of the key files must match the order of the certificates.
An optional parameter to specify a provider of the key store file. If not given, the provider is automatically detected based on the key store file type.
An optional parameter to select a specific key in the key store. When SNI is disabled, if the key store contains multiple keys and no alias is specified, the behavior is undefined.
An optional parameter to define the password for the key, in case it’s different from key-store-password If not given then it may be retrieved from CredentialsProvider.
An optional parameter to specify a provider of the trust store file. If not given, the provider is automatically detected based on the trust store file type.
Enables Server Name Indication (SNI), an TLS extension allowing the server to use multiple certificates. The client indicate the server name during the TLS handshake, allowing the server to select the right certificate.
Whether the files sent using multipart/form-data will be stored locally.
If true, they will be stored in quarkus.http.body-handler.uploads-directory and will be made available via io.vertx.ext.web.RoutingContext.fileUploads(). Otherwise, the files sent using multipart/form-data will not be stored locally, and io.vertx.ext.web.RoutingContext.fileUploads() will always return an empty collection. Note that even with this option being set to false, the multipart/form-data requests will be accepted.
The directory where the files sent using multipart/form-data should be stored.
Either an absolute path or a path relative to the current directory of the application process.
Whether the form attributes should be added to the request parameters.
If true, the form attributes will be added to the request parameters; otherwise the form parameters will not be added to the request parameters
Whether the uploaded files should be removed after serving the request.
If true the uploaded files stored in quarkus.http.body-handler.uploads-directory will be removed after handling the request. Otherwise, the files will be left there forever.
Whether the body buffer should pre-allocated based on the Content-Length header value.
If true the body buffer is pre-allocated according to the size read from the Content-Length header. Otherwise, the body buffer is pre-allocated to 1KB, and is resized dynamically
A comma-separated list of ContentType to indicate whether a given multipart field should be handled as a file part. You can use this setting to force HTTP-based extensions to parse a message part as a file based on its content type. For now, this setting only works when using RESTEasy Reactive.
If this is true then the address, scheme etc. will be set from headers forwarded by the proxy server, such as X-Forwarded-For. This should only be set if you are behind a proxy that sets these headers.
If this is true and proxy address forwarding is enabled then the standard Forwarded header will be used. In case the not standard X-Forwarded-For header is enabled and detected on HTTP requests, the standard header has the precedence. Activating this together with quarkus.http.proxy.allow-x-forwarded has security implications as clients can forge requests with a forwarded header that is not overwritten by the proxy. Therefore, proxies should strip unexpected X-Forwarded or X-Forwarded-* headers from the client.
If either this or allow-forwarded are true and proxy address forwarding is enabled then the not standard Forwarded header will be used. In case the standard Forwarded header is enabled and detected on HTTP requests, the standard header has the precedence. Activating this together with quarkus.http.proxy.allow-forwarded has security implications as clients can forge requests with a forwarded header that is not overwritten by the proxy. Therefore, proxies should strip unexpected X-Forwarded or X-Forwarded-* headers from the client.
Configure the list of trusted proxy addresses. Received Forwarded, X-Forwarded or X-Forwarded-* headers from any other proxy address will be ignored. The trusted proxy address should be specified as the IP address (IPv4 or IPv6), hostname or Classless Inter-Domain Routing (CIDR) notation. Please note that Quarkus needs to perform DNS lookup for all hostnames during the request. For that reason, using hostnames is not recommended. Examples of a socket address in the form of host or host:port:
- 127.0.0.1:8084
- [0:0:0:0:0:0:0:1]
- [0:0:0:0:0:0:0:1]:8084
- [::]
- localhost
- localhost:8084 Examples of a CIDR notation:
- ::/128
- ::/0
- 127.0.0.0/8 Please bear in mind that IPv4 CIDR won’t match request sent from the IPv6 address and the other way around.
The HTTP policy that this permission set is linked to. There are 3 built in policies: permit, deny and authenticated. Role based policies can be defined, and extensions can add their own policies.
The methods that this permission set applies to. If this is not set then they apply to all methods. Note that if a request matches any path from any permission set, but does not match the constraint due to the method not being listed then the request will be denied. Method specific permissions take precedence over matches that do not have any methods set. This means that for example if Quarkus is configured to allow GET and POST requests to /admin to and no other permissions are configured PUT requests to /admin will be denied.
The paths that this permission check applies to. If the path ends in /* then this is treated as a path prefix, otherwise it is treated as an exact match. Matches are done on a length basis, so the most specific path match takes precedence. If multiple permission sets match the same path then explicit methods matches take precedence over matches without methods set, otherwise the most restrictive permissions are applied.
Path specific authentication mechanism which must be used to authenticate a user. It needs to match HttpCredentialTransport authentication scheme such as 'basic', 'bearer', 'form', etc.
Permissions granted to the SecurityIdentity if this policy is applied successfully (the policy allows request to proceed) and the authenticated request has required role. For example, you can map permission perm1 with actions action1 and action2 to role admin by setting quarkus.http.auth.policy.role-policy1.permissions.admin=perm1:action1,perm1:action2 configuration property. Granted permissions are used for authorization with the @PermissionsAllowed annotation.
Permissions granted by this policy will be created with a java.security.Permission implementation specified by this configuration property. The permission class must declare exactly one constructor that accepts permission name (String) or permission name and actions (String, String[]).
If Dev Services for Elasticsearch has been explicitly enabled or disabled. Dev Services are generally enabled by default, unless there is an existing configuration present. For Elasticsearch, Dev Services starts a server unless quarkus.elasticsearch.hosts is set.
Indicates if the Elasticsearch server managed by Quarkus Dev Services is shared. When shared, Quarkus looks for running containers using label-based service discovery. If a matching container is found, it is used, and so a second one is not started. Otherwise, Dev Services for Elasticsearch starts a new container.
The discovery uses the quarkus-dev-service-elasticsearch label. The value is configured using the service-name property.
Container sharing is only used in dev mode.
The value of the quarkus-dev-service-elasticsearch label attached to the started container. This property is used when shared is set to true. In this case, before starting a container, Dev Services for Elasticsearch looks for a container with the quarkus-dev-service-elasticsearch label set to the configured value. If found, it will use this container instead of starting a new one. Otherwise it starts a new container with the quarkus-dev-service-elasticsearch label set to the specified value.
This property is used when you need multiple shared Elasticsearch servers.
The number of IO thread. By default, this is the number of locally detected processors.
Thread counts higher than the number of processors should not be necessary because the I/O threads rely on non-blocking operations, but you may want to use a thread count lower than the number of processors.
Determine if the OAuth2 extension is enabled. Enabled by default if you include the elytron-security-oauth2 dependency, so this would be used to disable it.
The OAuth2 server certificate file. Warning: this is not supported in native mode where the certificate must be included in the truststore used during the native image generation, see Using SSL With Native Executables.
If the properties are stored in plain text. If this is false (the default) then it is expected that the passwords are of the form HEX( MD5( username ":" realm ":" password ) )
If the properties are stored in plain text. If this is false (the default) then it is expected that the passwords are of the form HEX( MD5( username ":" realm ":" password ) )
Comma-separated list of locations to scan recursively for migrations. The location type is determined by its prefix.
Unprefixed locations or locations starting with classpath: point to a package on the classpath and may contain both SQL and Java-based migrations.
Locations starting with filesystem: point to a directory on the filesystem, may only contain SQL migrations and are only scanned recursively down non-hidden directories.
Comma-separated list of fully qualified class names of Callback implementations to use to hook into the Flyway lifecycle. The org.flywaydb.core.api.callback.Callback subclass must have a no-args constructor and must not be abstract. These classes must also not have any fields that hold state (unless that state is initialized in the constructor).
The maximum number of retries when attempting to connect to the database. After each failed attempt, Flyway will wait 1 second before attempting to connect again, up to the maximum number of times specified by connectRetries.
Sets the default schema managed by Flyway. This schema name is case-sensitive. If not specified, but schemas is, Flyway uses the first schema in that list. If that is also not specified, Flyway uses the default schema for the database connection.
Consequences:
- This schema will be the one containing the schema history table.
- This schema will be the default for the database connection (provided the database supports this concept).
The username that Flyway uses to connect to the database. If no specific JDBC URL is configured, falls back to the datasource username if not specified.
The password that Flyway uses to connect to the database. If no specific JDBC URL is configured, falls back to the datasource password if not specified.
Comma-separated case-sensitive list of schemas managed by Flyway. The first schema in the list will be automatically set as the default one during the migration. It will also be the one containing the schema history table.
The name of Flyway’s schema history table. By default (single-schema mode), the schema history table is placed in the default schema for the connection provided by the datasource. When the flyway.schemas property is set (multi-schema mode), the schema history table is placed in the first schema of the list.
The file name prefix for versioned SQL migrations. Versioned SQL migrations have the following file name structure: prefixVERSIONseparatorDESCRIPTIONsuffix , which using the defaults translates to V1.1__My_description.sql
The file name prefix for repeatable SQL migrations. Repeatable SQL migrations have the following file name structure: prefixSeparatorDESCRIPTIONsuffix , which using the defaults translates to R__My_description.sql
Ignore missing migrations when reading the history table. When set to true migrations from older versions present in the history table but absent in the configured locations will be ignored (and logged as a warning), when false (the default) the validation step will fail.
Ignore future migrations when reading the history table. When set to true migrations from newer versions present in the history table but absent in the configured locations will be ignored (and logged as a warning), when false (the default) the validation step will fail.
Whether to validate migrations and callbacks whose scripts do not obey the correct naming convention. A failure can be useful to check that errors such as case sensitivity in migration prefixes have been corrected.
Ignore migrations during validate and repair according to a given list of patterns (see https://flywaydb.org/documentation/configuration/parameters/ignoreMigrationPatterns for more information). When this configuration is set, the ignoreFutureMigrations and ignoreMissingMigrations settings are ignored. Patterns are comma separated.
Comma-separated list of locations to scan recursively for migrations. The location type is determined by its prefix.
Unprefixed locations or locations starting with classpath: point to a package on the classpath and may contain both SQL and Java-based migrations.
Locations starting with filesystem: point to a directory on the filesystem, may only contain SQL migrations and are only scanned recursively down non-hidden directories.
Comma-separated list of fully qualified class names of Callback implementations to use to hook into the Flyway lifecycle. The org.flywaydb.core.api.callback.Callback subclass must have a no-args constructor and must not be abstract. These classes must also not have any fields that hold state (unless that state is initialized in the constructor).
The maximum number of retries when attempting to connect to the database. After each failed attempt, Flyway will wait 1 second before attempting to connect again, up to the maximum number of times specified by connectRetries.
Sets the default schema managed by Flyway. This schema name is case-sensitive. If not specified, but schemas is, Flyway uses the first schema in that list. If that is also not specified, Flyway uses the default schema for the database connection.
Consequences:
- This schema will be the one containing the schema history table.
- This schema will be the default for the database connection (provided the database supports this concept).
The username that Flyway uses to connect to the database. If no specific JDBC URL is configured, falls back to the datasource username if not specified.
The password that Flyway uses to connect to the database. If no specific JDBC URL is configured, falls back to the datasource password if not specified.
Comma-separated case-sensitive list of schemas managed by Flyway. The first schema in the list will be automatically set as the default one during the migration. It will also be the one containing the schema history table.
The name of Flyway’s schema history table. By default (single-schema mode), the schema history table is placed in the default schema for the connection provided by the datasource. When the flyway.schemas property is set (multi-schema mode), the schema history table is placed in the first schema of the list.
The file name prefix for versioned SQL migrations. Versioned SQL migrations have the following file name structure: prefixVERSIONseparatorDESCRIPTIONsuffix , which using the defaults translates to V1.1__My_description.sql
The file name prefix for repeatable SQL migrations. Repeatable SQL migrations have the following file name structure: prefixSeparatorDESCRIPTIONsuffix , which using the defaults translates to R__My_description.sql
Ignore missing migrations when reading the history table. When set to true migrations from older versions present in the history table but absent in the configured locations will be ignored (and logged as a warning), when false (the default) the validation step will fail.
Ignore future migrations when reading the history table. When set to true migrations from newer versions present in the history table but absent in the configured locations will be ignored (and logged as a warning), when false (the default) the validation step will fail.
Whether to validate migrations and callbacks whose scripts do not obey the correct naming convention. A failure can be useful to check that errors such as case sensitivity in migration prefixes have been corrected.
Ignore migrations during validate and repair according to a given list of patterns (see https://flywaydb.org/documentation/configuration/parameters/ignoreMigrationPatterns for more information). When this configuration is set, the ignoreFutureMigrations and ignoreMissingMigrations settings are ignored. Patterns are comma separated.
Cloud Event type (ce-type) that triggers this function. Default value is function name. This config item is only required when there is more than one function defined within the deployment. The ce-type is not looked at if there is only one function in the deployment. The message will just be dispatched to that function. This allows you to change the knative trigger binding without having to change the configuration of the quarkus deployment.
The function to export. If there is more than one function defined for this deployment, then you must set this variable. If there is only a single function, you do not have to set this config item.
The function name. Function names are specified on function classes using the @jakarta.inject.Named annotation. If this name is unspecified and there is exactly one unnamed function then this unnamed function will be used. If there is only a single named function and the name is unspecified then the named function will be used. These rules apply for each function implementation (HttpFunction, BackgroundFunction, RawBackgroundFunction).
Whether Hibernate Envers is enabled <strong>during the build</strong>.
If Hibernate Envers is disabled during the build, all processing related to Hibernate Envers will be skipped,
and the audit entities will not be added to the Hibernate ORM metamodel
nor to the database schema that Hibernate ORM generates,
but it will not be possible to use Hibernate Envers at runtime:
quarkus.hibernate-envers.active will default to false and setting it to true will lead to an error.
Whether Hibernate Envers should be active for this persistence unit at runtime.
If Hibernate Envers is not active, the audit entities will still be added to the Hibernate ORM metamodel
and to the database schema that Hibernate ORM generates:
you would need to disable Hibernate Envers at build time (i.e. set quarkus.hibernate-envers.enabled to false)
in order to avoid that.
However, when Hibernate Envers is not active, it will not process entity change events
nor create new versions of entities.
and accessing the AuditReader through AuditReaderFactory will not be possible.
Note that if Hibernate Envers is disabled (i.e. quarkus.hibernate-envers.enabled is set to false),
it won’t be active for any persistence unit, and setting this property to true will fail.
Enable the do_not_audit_optimistic_locking_field feature. Maps to org.hibernate.envers.configuration.EnversSettings#DO_NOT_AUDIT_OPTIMISTIC_LOCKING_FIELD.
Defines the suffix to be used for modified flag columns. Defaults to _MOD. Maps to org.hibernate.envers.configuration.EnversSettings#MODIFIED_FLAG_SUFFIX
Defines the fully qualified class name of a user defined revision listener. Maps to org.hibernate.envers.configuration.EnversSettings#REVISION_LISTENER.
Defines the property name for the audit entity’s composite primary key. Defaults to originalId. Maps to org.hibernate.envers.configuration.EnversSettings#ORIGINAL_ID_PROP_NAME.
Defines the column name that holds the end revision number in audit entities. Defaults to REVEND. Maps to org.hibernate.envers.configuration.EnversSettings#AUDIT_STRATEGY_VALIDITY_END_REV_FIELD_NAME.
Enables the audit_strategy_validity_store_revend_timestamp feature. Maps to org.hibernate.envers.configuration.EnversSettings#AUDIT_STRATEGY_VALIDITY_STORE_REVEND_TIMESTAMP.
Defines the column name of the revision end timestamp in the audit tables. Defaults to REVEND_TSTMP. Maps to org.hibernate.envers.configuration.EnversSettings#AUDIT_STRATEGY_VALIDITY_REVEND_TIMESTAMP_FIELD_NAME.
Defines the name of the column used for storing collection ordinal values for embeddable elements. Defaults to SETORDINAL. Maps to org.hibernate.envers.configuration.EnversSettings#EMBEDDABLE_SET_ORDINAL_FIELD_NAME.
Defines the naming strategy to be used for modified columns. Defaults to org.hibernate.envers.boot.internal.LegacyModifiedColumnNamingStrategy. Maps to org.hibernate.envers.configuration.EnversSettings#MODIFIED_COLUMN_NAMING_STRATEGY.
Whether Hibernate Envers should be active for this persistence unit at runtime.
If Hibernate Envers is not active, the audit entities will still be added to the Hibernate ORM metamodel
and to the database schema that Hibernate ORM generates:
you would need to disable Hibernate Envers at build time (i.e. set quarkus.hibernate-envers.enabled to false)
in order to avoid that.
However, when Hibernate Envers is not active, it will not process entity change events
nor create new versions of entities.
and accessing the AuditReader through AuditReaderFactory will not be possible.
Note that if Hibernate Envers is disabled (i.e. quarkus.hibernate-envers.enabled is set to false),
it won’t be active for any persistence unit, and setting this property to true will fail.
Enable the do_not_audit_optimistic_locking_field feature. Maps to org.hibernate.envers.configuration.EnversSettings#DO_NOT_AUDIT_OPTIMISTIC_LOCKING_FIELD.
Defines the suffix to be used for modified flag columns. Defaults to _MOD. Maps to org.hibernate.envers.configuration.EnversSettings#MODIFIED_FLAG_SUFFIX
Defines the fully qualified class name of a user defined revision listener. Maps to org.hibernate.envers.configuration.EnversSettings#REVISION_LISTENER.
Defines the property name for the audit entity’s composite primary key. Defaults to originalId. Maps to org.hibernate.envers.configuration.EnversSettings#ORIGINAL_ID_PROP_NAME.
Defines the column name that holds the end revision number in audit entities. Defaults to REVEND. Maps to org.hibernate.envers.configuration.EnversSettings#AUDIT_STRATEGY_VALIDITY_END_REV_FIELD_NAME.
Enables the audit_strategy_validity_store_revend_timestamp feature. Maps to org.hibernate.envers.configuration.EnversSettings#AUDIT_STRATEGY_VALIDITY_STORE_REVEND_TIMESTAMP.
Defines the column name of the revision end timestamp in the audit tables. Defaults to REVEND_TSTMP. Maps to org.hibernate.envers.configuration.EnversSettings#AUDIT_STRATEGY_VALIDITY_REVEND_TIMESTAMP_FIELD_NAME.
Defines the name of the column used for storing collection ordinal values for embeddable elements. Defaults to SETORDINAL. Maps to org.hibernate.envers.configuration.EnversSettings#EMBEDDABLE_SET_ORDINAL_FIELD_NAME.
Defines the naming strategy to be used for modified columns. Defaults to org.hibernate.envers.boot.internal.LegacyModifiedColumnNamingStrategy. Maps to org.hibernate.envers.configuration.EnversSettings#MODIFIED_COLUMN_NAMING_STRATEGY.
Whether Hibernate ORM is enabled during the build.
If Hibernate ORM is disabled during the build, all processing related to Hibernate ORM will be skipped,
but it will not be possible to activate Hibernate ORM at runtime:
quarkus.hibernate-orm.active will default to false and setting it to true will lead to an error.
Path to a file containing the SQL statements to execute when Hibernate ORM starts.
The file is retrieved from the classpath resources,
so it must be located in the resources directory (e.g. src/main/resources).
The default value for this setting differs depending on the Quarkus launch mode:
In dev and test modes, it defaults to import.sql.
Simply add an import.sql file in the root of your resources directory
and it will be picked up without having to set this property.
Pass no-file to force Hibernate ORM to ignore the SQL import file.
In production mode, it defaults to no-file.
It means Hibernate ORM won’t try to execute any SQL import file by default.
Pass an explicit value to force Hibernate ORM to execute the SQL import file.
If you need different SQL statements between dev mode, test (@QuarkusTest) and in production, use Quarkus
configuration profiles facility.
Pluggable strategy contract for applying physical naming rules for database object names. Class name of the Hibernate PhysicalNamingStrategy implementation
Pluggable strategy for applying implicit naming rules when an explicit name is not given. Class name of the Hibernate ImplicitNamingStrategy implementation
Not all customization options exposed by
org.hibernate.boot.MetadataBuilder
will work correctly. Stay clear of options related to classpath scanning in particular.
This setting is exposed mainly to allow registration of types, converters and SQL functions.
XML files to configure the entity mapping, e.g. META-INF/my-orm.xml.
Defaults to META-INF/orm.xml if it exists. Pass no-file to force Hibernate ORM to ignore META-INF/orm.xml.
Identifiers can be quoted using one of the available strategies.
Set to none by default, meaning no identifiers will be quoted. If set to all, all identifiers and column definitions will be quoted. Additionally, setting it to all-except-column-definitions will skip the column definitions, which can usually be required when they exist, or else use the option only-keywords to quote only identifiers deemed SQL keywords by the Hibernate ORM dialect.
tooltip:none[No optimizer, resulting in a database call each and every time an identifier value is needed from the generator.
Not recommended in production environments:
may result in degraded performance and/or frequent gaps in identifier values.], all, all-except-column-definitions, only-keywords
The default in Quarkus is for 2nd level caching to be enabled, and a good implementation is already integrated for you.
Just cherry-pick which entities should be using the cache.
Set this to false to disable all 2nd level caches.
Defines the method for multi-tenancy (DATABASE, NONE, SCHEMA). The complete list of allowed values is available in the
Hibernate ORM
JavaDoc.
The type DISCRIMINATOR is currently not supported. The default value is NONE (no multi-tenancy).
If hibernate is not auto generating the schema, and Quarkus is running in development mode then Quarkus will attempt to validate the database after startup and print a log message if there are any problems.
Whether session metrics should be appended into the server log for each Hibernate session. This only has effect if statistics are enabled (quarkus.hibernate-orm.statistics). The default is false (which means both statistics and log-session-metrics need to be enabled for the session metrics to appear in the log).
Whether this persistence unit should be active at runtime.
If the persistence unit is not active, it won’t start with the application,
and accessing the corresponding EntityManagerFactory/EntityManager or SessionFactory/Session
will not be possible.
Note that if Hibernate ORM is disabled (i.e. quarkus.hibernate-orm.enabled is set to false),
all persistence units are deactivated, and setting this property to true will fail.
Properties that should be passed on directly to Hibernate ORM.
Use the full configuration property key here,
for instance quarkus.hibernate-orm.unsupported-properties."hibernate.order_inserts" = true.
Properties set here are completely unsupported:
as Quarkus doesn’t generally know about these properties and their purpose,
there is absolutely no guarantee that they will work correctly,
and even if they do, that may change when upgrading to a newer version of Quarkus
(even just a micro/patch version).
Consider using a supported configuration property before falling back to unsupported ones.
If none exists, make sure to file a feature request so that a supported configuration property can be added to Quarkus,
and more importantly so that the configuration property is tested regularly.
When set, attempts to exchange data with the database
as the given version of Hibernate ORM would have,
on a best-effort basis.
Please note:
schema validation may still fail in some cases:
this attempts to make Hibernate ORM 6+ behave correctly at runtime,
but it may still expect a different (but runtime-compatible) schema.
robust test suites are still useful and recommended:
you should still check that your application behaves as intended with your legacy schema.
this feature is inherently unstable:
some aspects of it may stop working in future versions of Quarkus,
and older versions will be dropped as Hibernate ORM changes pile up
and support for those older versions becomes too unreliable.
Select whether the database schema is generated or not. drop-and-create is awesome in development mode. This defaults to 'none', however if Dev Services is in use and no other extensions that manage the schema are present this will default to 'drop-and-create'. Accepted values: none, create, drop-and-create, drop, update, validate.
Setting the dialect directly is only recommended as a last resort:
most popular databases have a corresponding Quarkus extension,
allowing Quarkus to select the dialect automatically,
in which case you do not need to set the dialect at all,
though you may want to set
quarkus.datasource.db-version as
high as possible
to benefit from the best performance and latest features.
If your database does not have a corresponding Quarkus extension,
you will need to set the dialect directly.
In that case, keep in mind that the JDBC driver and Hibernate ORM dialect
may not work properly in GraalVM native executables.
Equivalent to native if supported, normalize-utc otherwise.
auto
Equivalent to native if supported, column otherwise.
native
Stores the timestamp and timezone in a column of type timestamp with time zone.
Only available on some databases/dialects;
if not supported, an exception will be thrown during static initialization.
column
Stores the timezone in a separate column next to the timestamp column.
Use @TimeZoneColumn on the relevant entity property to customize the timezone column.
normalize-utc
Does not store the timezone, and loses timezone information upon persisting.
Instead, normalizes the value to a timestamp in the UTC timezone.
normalize
Does not store the timezone, and loses timezone information upon persisting.
Instead, normalizes the value:
* upon persisting to the database, to a timestamp in the JDBC timezone
set through quarkus.hibernate-orm.jdbc.timezone,
or the JVM default timezone if not set.
* upon reading back from the database, to the JVM default timezone.
+
Use this to get the legacy behavior of Quarkus 2 / Hibernate ORM 5 or older.
The optimizer to apply to identifier generators
whose optimizer is not configured explicitly.
Only relevant for table- and sequence-based identifier generators.
Other generators, such as UUID-based generators, will ignore this setting.
The optimizer is responsible for pooling new identifier values,
in order to reduce the frequency of database calls to retrieve those values
and thereby improve performance.
Existing applications rely (implicitly or explicitly) on Hibernate ignoring any DiscriminatorColumn declarations on joined inheritance hierarchies. This setting allows these applications to maintain the legacy behavior of DiscriminatorColumn annotations being ignored when paired with joined inheritance.
Path to a file containing the SQL statements to execute when Hibernate ORM starts.
The file is retrieved from the classpath resources,
so it must be located in the resources directory (e.g. src/main/resources).
The default value for this setting differs depending on the Quarkus launch mode:
In dev and test modes, it defaults to import.sql.
Simply add an import.sql file in the root of your resources directory
and it will be picked up without having to set this property.
Pass no-file to force Hibernate ORM to ignore the SQL import file.
In production mode, it defaults to no-file.
It means Hibernate ORM won’t try to execute any SQL import file by default.
Pass an explicit value to force Hibernate ORM to execute the SQL import file.
If you need different SQL statements between dev mode, test (@QuarkusTest) and in production, use Quarkus
configuration profiles facility.
Pluggable strategy contract for applying physical naming rules for database object names. Class name of the Hibernate PhysicalNamingStrategy implementation
Pluggable strategy for applying implicit naming rules when an explicit name is not given. Class name of the Hibernate ImplicitNamingStrategy implementation
Not all customization options exposed by
org.hibernate.boot.MetadataBuilder
will work correctly. Stay clear of options related to classpath scanning in particular.
This setting is exposed mainly to allow registration of types, converters and SQL functions.
XML files to configure the entity mapping, e.g. META-INF/my-orm.xml.
Defaults to META-INF/orm.xml if it exists. Pass no-file to force Hibernate ORM to ignore META-INF/orm.xml.
Identifiers can be quoted using one of the available strategies.
Set to none by default, meaning no identifiers will be quoted. If set to all, all identifiers and column definitions will be quoted. Additionally, setting it to all-except-column-definitions will skip the column definitions, which can usually be required when they exist, or else use the option only-keywords to quote only identifiers deemed SQL keywords by the Hibernate ORM dialect.
tooltip:none[No optimizer, resulting in a database call each and every time an identifier value is needed from the generator.
Not recommended in production environments:
may result in degraded performance and/or frequent gaps in identifier values.], all, all-except-column-definitions, only-keywords
The default in Quarkus is for 2nd level caching to be enabled, and a good implementation is already integrated for you.
Just cherry-pick which entities should be using the cache.
Set this to false to disable all 2nd level caches.
Defines the method for multi-tenancy (DATABASE, NONE, SCHEMA). The complete list of allowed values is available in the
Hibernate ORM
JavaDoc.
The type DISCRIMINATOR is currently not supported. The default value is NONE (no multi-tenancy).
If hibernate is not auto generating the schema, and Quarkus is running in development mode then Quarkus will attempt to validate the database after startup and print a log message if there are any problems.
Whether this persistence unit should be active at runtime.
If the persistence unit is not active, it won’t start with the application,
and accessing the corresponding EntityManagerFactory/EntityManager or SessionFactory/Session
will not be possible.
Note that if Hibernate ORM is disabled (i.e. quarkus.hibernate-orm.enabled is set to false),
all persistence units are deactivated, and setting this property to true will fail.
Properties that should be passed on directly to Hibernate ORM.
Use the full configuration property key here,
for instance quarkus.hibernate-orm.unsupported-properties."hibernate.order_inserts" = true.
Properties set here are completely unsupported:
as Quarkus doesn’t generally know about these properties and their purpose,
there is absolutely no guarantee that they will work correctly,
and even if they do, that may change when upgrading to a newer version of Quarkus
(even just a micro/patch version).
Consider using a supported configuration property before falling back to unsupported ones.
If none exists, make sure to file a feature request so that a supported configuration property can be added to Quarkus,
and more importantly so that the configuration property is tested regularly.
Setting the dialect directly is only recommended as a last resort:
most popular databases have a corresponding Quarkus extension,
allowing Quarkus to select the dialect automatically,
in which case you do not need to set the dialect at all,
though you may want to set
quarkus.datasource.db-version as
high as possible
to benefit from the best performance and latest features.
If your database does not have a corresponding Quarkus extension,
you will need to set the dialect directly.
In that case, keep in mind that the JDBC driver and Hibernate ORM dialect
may not work properly in GraalVM native executables.
Equivalent to native if supported, normalize-utc otherwise.
auto
Equivalent to native if supported, column otherwise.
native
Stores the timestamp and timezone in a column of type timestamp with time zone.
Only available on some databases/dialects;
if not supported, an exception will be thrown during static initialization.
column
Stores the timezone in a separate column next to the timestamp column.
Use @TimeZoneColumn on the relevant entity property to customize the timezone column.
normalize-utc
Does not store the timezone, and loses timezone information upon persisting.
Instead, normalizes the value to a timestamp in the UTC timezone.
normalize
Does not store the timezone, and loses timezone information upon persisting.
Instead, normalizes the value:
* upon persisting to the database, to a timestamp in the JDBC timezone
set through quarkus.hibernate-orm.jdbc.timezone,
or the JVM default timezone if not set.
* upon reading back from the database, to the JVM default timezone.
+
Use this to get the legacy behavior of Quarkus 2 / Hibernate ORM 5 or older.
The optimizer to apply to identifier generators
whose optimizer is not configured explicitly.
Only relevant for table- and sequence-based identifier generators.
Other generators, such as UUID-based generators, will ignore this setting.
The optimizer is responsible for pooling new identifier values,
in order to reduce the frequency of database calls to retrieve those values
and thereby improve performance.
Select whether the database schema is generated or not. drop-and-create is awesome in development mode. This defaults to 'none', however if Dev Services is in use and no other extensions that manage the schema are present this will default to 'drop-and-create'. Accepted values: none, create, drop-and-create, drop, update, validate.
Existing applications rely (implicitly or explicitly) on Hibernate ignoring any DiscriminatorColumn declarations on joined inheritance hierarchies. This setting allows these applications to maintain the legacy behavior of DiscriminatorColumn annotations being ignored when paired with joined inheritance.
Whether Hibernate Search is enabled during the build.
If Hibernate Search is disabled during the build, all processing related to Hibernate Search will be skipped,
but it will not be possible to activate Hibernate Search at runtime:
quarkus.hibernate-search-orm.active will default to false and setting it to true will lead to an error.
A bean reference to a component
that should be notified of any failure occurring in a background process
(mainly index operations).
The referenced bean must implement FailureHandler.
Instead of setting this configuration property,
you can simply annotate your custom FailureHandler implementation with @SearchExtension
and leave the configuration property unset: Hibernate Search will use the annotated implementation automatically.
If this configuration property is set, it takes precedence over any @SearchExtension annotation.
Whether Hibernate Search should be active for this persistence unit at runtime.
If Hibernate Search is not active, it won’t index Hibernate ORM entities,
and accessing the SearchMapping/SearchSession of the relevant persistence unit
for search or other operation will not be possible.
Note that if Hibernate Search is disabled (i.e. quarkus.hibernate-search-orm.enabled is set to false),
it won’t be active for any persistence unit, and setting this property to true will fail.
The schema management strategy, controlling how indexes and their schema
are created, updated, validated or dropped on startup and shutdown.
Available values:
Strategy
Definition
none
Do nothing: assume that indexes already exist and that their schema matches Hibernate Search’s expectations.
validate
Validate that indexes exist and that their schema matches Hibernate Search’s expectations.
If it does not, throw an exception, but make no attempt to fix the problem.
create
For indexes that do not exist, create them along with their schema.
For indexes that already exist, do nothing: assume that their schema matches Hibernate Search’s expectations.
create-or-validate (default unless using Dev Services)
For indexes that do not exist, create them along with their schema.
For indexes that already exist, validate that their schema matches Hibernate Search’s expectations.
If it does not, throw an exception, but make no attempt to fix the problem.
create-or-update
For indexes that do not exist, create them along with their schema.
For indexes that already exist, validate that their schema matches Hibernate Search’s expectations;
if it does not match expectations, try to update it.
This strategy is unfit for production environments,
due to several important limitations,
but can be useful when developing.
drop-and-create
For indexes that do not exist, create them along with their schema.
For indexes that already exist, drop them, then create them along with their schema.
drop-and-create-and-drop (default when using Dev Services)
For indexes that do not exist, create them along with their schema.
For indexes that already exist, drop them, then create them along with their schema.
The synchronization strategy to use when indexing automatically.
Defines how complete indexing should be before resuming the application thread
after a database transaction is committed.
Indexing synchronization is only relevant when coordination is disabled (which is the default).
With the outbox-polling coordination strategy,
indexing happens in background threads and is always asynchronous;
the behavior is equivalent to the write-sync synchronization strategy.
Available values:
Strategy
Throughput
Guarantees when the application thread resumes
Changes applied
Changes safe from crash/power loss
Changes visible on search
async
Best
write-sync (default)
Medium
read-sync
Medium to worst
sync
Worst
This property also accepts a bean reference
to a custom implementations of AutomaticIndexingSynchronizationStrategy.
Instead of setting this configuration property,
you can simply annotate your custom AutomaticIndexingSynchronizationStrategy implementation with @SearchExtension
and leave the configuration property unset: Hibernate Search will use the annotated implementation automatically.
If this configuration property is set, it takes precedence over any @SearchExtension annotation.
As the schema is generated without a connection to the server, this item is mandatory.
It doesn’t have to be the exact version (it can be 7 or 7.1 for instance) but it has to be sufficiently precise
to choose a model dialect (the one used to generate the schema) compatible with the protocol dialect (the one used
to communicate with Elasticsearch).
There’s no rule of thumb here as it depends on the schema incompatibilities introduced by Elasticsearch versions. In
any case, if there is a problem, you will have an error when Hibernate Search tries to connect to the cluster.
A bean reference to the component
used to configure layout (e.g. index names, index aliases).
The referenced bean must implement IndexLayoutStrategy.
Available built-in implementations:
simple
The default, future-proof strategy: if the index name in Hibernate Search is myIndex,
this strategy will create an index named myindex-000001, an alias for write operations named myindex-write,
and an alias for read operations named myindex-read.
no-alias
A strategy without index aliases, mostly useful on legacy clusters:
if the index name in Hibernate Search is myIndex,
this strategy will create an index named myindex, and will not use any alias.
Instead of setting this configuration property,
you can simply annotate your custom IndexLayoutStrategy implementation with @SearchExtension
and leave the configuration property unset: Hibernate Search will use the annotated implementation automatically.
If this configuration property is set, it takes precedence over any @SearchExtension annotation.
Path to a file in the classpath holding custom index settings to be included in the index definition
when creating an Elasticsearch index.
The provided settings will be merged with those generated by Hibernate Search, including analyzer definitions.
When analysis is configured both through an analysis configurer and these custom settings, the behavior is undefined;
it should not be relied upon.
Path to a file in the classpath holding a custom index mapping to be included in the index definition
when creating an Elasticsearch index.
The file does not need to (and generally shouldn’t) contain the full mapping:
Hibernate Search will automatically inject missing properties (index fields) in the given mapping.
Instead of setting this configuration property,
you can simply annotate your custom ElasticsearchAnalysisConfigurer implementation with @SearchExtension
and leave the configuration property unset: Hibernate Search will use the annotated implementation automatically.
If this configuration property is set, it takes precedence over any @SearchExtension annotation.