jakartaee / jakartaee/validation
Clarify that placing `@Valid` on the containers to validate container elements is discouraged
- Dominant language
- Java
- Stars
- 163
- Forks
- 67
- Avg merge
- 3d 15h
- Merged PRs (30d)
- 2
Description
Having the code as
```java
@Valid
List strings
```
to apply cascading validation to the list elements is trailing from the BV 1.0 1.1 specs and in BV 2.0 the new way to define such constraints was introduced (using type argument annotations):
```java
List<@Valid MyObject> strings
```
We should highlight to the users that applying cascading validation in a "legacy-way" will not be supported anymore in future versions of the spec, and that
```java
@Valid
List strings
```
would mean that cascading validation is applied to the container itself (i.e. to the list and its properties) rather than its elements. Implementations of the current spec are encouraged to warn their users about this planned change and guide them to migrate to the correct way of achieving this through the usage of a type argument annotation
Things to also update:
- Examples in https://jakarta.ee/specifications/bean-validation/3.1/jakarta-validation-spec-3.1.html#constraintdeclarationvalidationprocess-requirements-graphvalidation-examples make sure that the "traditional style" is now "discouraged" instead.
Contributor guide
Research direction
Open the Jakarta Validation 3.1 specification section linked in the issue and review its container-element validation examples. Update the guidance to discourage the traditional @Valid placement, explain its container-level meaning, and show the type-argument annotation as the preferred form; the revised examples and wording should clearly reflect this migration guidance.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 52/100