Hey there,
I did not spend a lot of time looking into it but scanning through the Bean Validation spec to refresh my memory, here is what comes up for me.
I think the semantic is closer to a @ValidateOnExecution annotation than @Valid which has specific cascading semantics irrespective of *when* the validation happens. I don't remember the exact reasons but we did not reuse @Valid for the usages of
@ValidateOnExecution.It might even be reusing @ValidateOnExecution for that matter (would need to add the extra TARGET)
If @Valid is used (which I think would be the wrong choice, here is a cursory list of what should be looked after to make sure it does not break things
- TraversableResolver and Node
- Concept of class parameterized providing inheritance to the usage site (e.g. T getFoo() in heriting Bar<@Valid T>
- This implied the traversal rules that are quite non trivial
- The data repo interface Would have a ValueExtractor implementation?
- ExecutableValidator like interface for these containers?
- Metadata API changes
- figure out how make Group and its annotations work the same if we go that way
So far these concepts are under chapter 11 of the bean validation spec as it describe integration standard semantics with other technologies (CDI, JPA, JSF, Jakarta EE etc)
Emmanuel