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
There is a known issue with standard bean validation and Kotlin coroutine method, which we cannot address here, see #344, but as it stands our built-in support applies bean validation to every controller method as long as it's on the classpath. That means if you do want bean validation in some places, you can't opt out of it for coroutine methods even if they don't need it.
We should improve how the built-in validation support gets applied. For example, on startup, check if a controller method or its parameters has @Valid, or any other annotations marked with @Constraint. We'll also use Validator#getConstraintsForClass to check for constrained properties on complex Objects. Once we know what methods need validation, we'll use that at runtime to apply validation only where it is expected.
The text was updated successfully, but these errors were encountered:
There is a known issue with standard bean validation and Kotlin coroutine method, which we cannot address here, see #344, but as it stands our built-in support applies bean validation to every controller method as long as it's on the classpath. That means if you do want bean validation in some places, you can't opt out of it for coroutine methods even if they don't need it.
We should improve how the built-in validation support gets applied. For example, on startup, check if a controller method or its parameters has
@Valid
, or any other annotations marked with@Constraint
. We'll also useValidator#getConstraintsForClass
to check for constrained properties on complex Objects. Once we know what methods need validation, we'll use that at runtime to apply validation only where it is expected.The text was updated successfully, but these errors were encountered: