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
At the moment, Hilla looks for a bean of type Validator, and if nothing found, it falls back the default from Jakarta API.
Most of the times, the defaults are needed, and the user wants to add some custom validators on top. Hilla can make it easier for the users to define as many custom validators as they want to complement the defaults, not to replace it.
Describe the solution you'd like
The main motivation of this enhancement issue is to the enable users introducing as many Validator beans to use them on top of the default from Jakarta API.
Then, if possible, the framework can expect an optional bean of type ValidatorFactory to enable users for completely opting out from the default, and introduce their own universal Validator.
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered:
jakarta.validation.Validator does not support customization. It can be replaced with a custom implementation, that could wrap the default. This should be already possible in Hilla, by creating a Spring Bean that implements Validator.
I was mostly picturing it as looking up all the Validator beans, and validate parameters against all of them (including the default from Jakarta).
taefi
changed the title
Enable adding new validator by defining spring beans to complement the default Validator
Enable adding new validators by defining spring beans to complement the default Validator
Feb 10, 2025
Describe your motivation
At the moment, Hilla looks for a bean of type
Validator
, and if nothing found, it falls back the default from Jakarta API.Most of the times, the defaults are needed, and the user wants to add some custom validators on top. Hilla can make it easier for the users to define as many custom validators as they want to complement the defaults, not to replace it.
Describe the solution you'd like
The main motivation of this enhancement issue is to the enable users introducing as many
Validator
beans to use them on top of the default from Jakarta API.Then, if possible, the framework can expect an optional bean of type
ValidatorFactory
to enable users for completely opting out from the default, and introduce their own universalValidator
.Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: