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
If this build item is generated, then it means that there is a recorder step that can be used as a point at which the application loading during AppCDS generation can be stopped safely, therefore allowing Quarkus to not have to stop loading the application in the static init phase which is the default approach for AppCDS generation.
A build item that allows extensions to declare which keys should not be propagated before a task is executed in the `ContextHandler#runWith(Runnable,Object)` method.
When Quarkus builds a gRPC server instance, users can apply their own Server(Builder) customizers. The customizers are applied by `priority`, the higher the number the later customizer is applied. The customizers are applied before Quarkus applies user's server configuration; e.g. ideal for some initial defaults.
260
+
261
+
There are two `customize` methods, the first one uses gRPC's `ServerBuilder` as a parameter - to be used with Quarkus' legacy gRPC support, where the other uses `GrpcServerOptions` - to be used with the new Vert.x gRPC support. User should implement the right `customize` method per gRPC support type usage, or both if the customizer is gRPC type neutral.
262
+
263
+
[source, java]
264
+
----
265
+
public interface ServerBuilderCustomizer<T extends ServerBuilder<T>> {
266
+
267
+
/**
268
+
* Customize a ServerBuilder instance.
269
+
*
270
+
* @param config server's configuration
271
+
* @param builder Server builder instance
272
+
*/
273
+
default void customize(GrpcServerConfiguration config, T builder) {
Copy file name to clipboardExpand all lines: _versions/main/guides/hibernate-orm.adoc
+78Lines changed: 78 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1569,3 +1569,81 @@ Format mappers *must* have both `@PersistenceUnitExtension` and either `@JsonFor
1569
1569
1570
1570
Having multiple JSON (or XML) format mappers registered for the same persistence unit will result in an exception, because of the ambiguity.
1571
1571
====
1572
+
1573
+
[[validator_integration]]
1574
+
== Validation modes and Hibernate Validator integration
1575
+
1576
+
Hibernate Validator integration into Hibernate ORM opens up the following capabilities:
1577
+
1578
+
- performing entity validation on lifecycle events
1579
+
- applying constraint information from entities to DDL
1580
+
1581
+
From Quarkus's perspective, this is controlled by the <<quarkus-hibernate-orm_quarkus-hibernate-orm-validation-mode,`quarkus.hibernate-orm.validation.mode` configuration property>>.
1582
+
The available validation modes are:
1583
+
1584
+
- `auto` -- the default option; works the same as `callback` and `ddl` enabled simultaneously
1585
+
when the application uses `quarkus-hibernate-validator`,
1586
+
and as `none` otherwise.
1587
+
- `callback` -- Hibernate Validator will perform the lifecycle event validation.
1588
+
- `ddl` -- Hibernate Validator constraints will be considered for the <<dev-mode,DDL operations>>
1589
+
- `none` -- Hibernate Validator integration will be disabled.
1590
+
1591
+
While all constraints with corresponding Jakarta Validation rules will apply during the `callback` validation,
1592
+
in the `ddl` mode, only a subset of constraints is used to influence the DDL.
1593
+
In the Hibernate Validator documentation, you can find link:{hibernate-validator-docs-url}#section-builtin-constraints[the list of available constraints] and their impact on the DDL generation.
1594
+
1595
+
Let's consider having a simple entity with some constraints applied to its properties:
1596
+
1597
+
[source,java]
1598
+
----
1599
+
import jakarta.validation.constraints.NotEmpty;
1600
+
import jakarta.validation.constraints.NotNull;
1601
+
import jakarta.validation.constraints.Size;
1602
+
1603
+
@Entity
1604
+
public class MyEntity {
1605
+
@Id
1606
+
public long id;
1607
+
1608
+
@NotNull
1609
+
@NotEmpty
1610
+
@Size(max = 50)
1611
+
public String name;
1612
+
1613
+
public String value;
1614
+
}
1615
+
----
1616
+
1617
+
With the `ddl` mode enabled, the resulting schema would be expected to have the following constraints:
1618
+
[source,sql]
1619
+
----
1620
+
create table myentity
1621
+
(
1622
+
id bigint not null primary key,
1623
+
name varchar(50) not null, // <1>
1624
+
value varchar(255), // <2>
1625
+
);
1626
+
----
1627
+
<1> The `name` column has a `not null` constraint because of the `@NotNull` constraint,
1628
+
and the length of the values is limited to `50` because of the `@Size(max=50)` constraint.
1629
+
+
1630
+
<2> Since the `value` property in the entity has no constraints, there are no additional constraints in the DDL,
1631
+
and the `255` length limit comes from the default `jakarta.persistence.Column#lenght()`.
1632
+
1633
+
With the `callback` mode, expect getting a `jakarta.validation.ConstraintViolationException` thrown:
The xref:hibernate-reactive-panache.adoc[Hibernate Reactive with Panache] extension facilitates the usage of Hibernate Reactive
334
334
by providing active record style entities (and repositories) and focuses on making your entities trivial and fun to write in Quarkus.
335
335
336
+
== Validation modes and Hibernate Validator integration
337
+
338
+
To find out more on how the <<quarkus-hibernate-orm_quarkus-hibernate-orm-validation-mode,`quarkus.hibernate-orm.validation.mode` configuration property>>.
339
+
influence your Hibernate Reactive application see the xref:hibernate-orm.adoc#validator_integration[corresponding Hibernate ORM guide],
Copy file name to clipboardExpand all lines: _versions/main/guides/security-customization.adoc
+48Lines changed: 48 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -741,6 +741,54 @@ Depending on the application, that can be a lot of the `AuthenticationSuccessEve
741
741
For that reason, asynchronous processing can have positive effect on performance.
742
742
<2> Common code for all supported security event types is possible because they all implement the `io.quarkus.security.spi.runtime.SecurityEvent` interface.
743
743
744
+
== `SecurityIdentity` injection in Vert.x route handlers
745
+
746
+
When you need to inject `SecurityIdentity` in a Vert.x route handler registered directly on the xref:reactive-routes.adoc#using-vertx-web-router[Vert.x Web Router], then requesting the `SecurityIdentity` propagation is required.
747
+
For example:
748
+
749
+
[source,java]
750
+
----
751
+
package io.quarkus.it.security;
752
+
753
+
public class RouterObserver {
754
+
755
+
public void route(@Observes Router router, UserInformation userInformation) {
<1> Propagate the `SecurityIdentity` when a Vert.x route handler is registered programmatically on the Vert.x HTTP router.
789
+
It is required because Quarkus cannot detect that the `SecurityIdentity` injection point is used in the programmatically registered Vert.x route handler.
790
+
For the routes registered declaratively with the `@Route` annotation as well as Jakarta REST endpoints, this configuration is not required.
0 commit comments