refactor: introduce class responsible for how bean validation annotations affect schemas #5047
+286
−179
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull Request
Thank you for contributing to swagger-core!
Please fill out the following information to help us review your PR efficiently.
Description
This is a step towards exposing an easier way of extending how
BeanValidatorAnnotationscan be introspected and added to the generated schema. It is a sometimes reoccurring request to add different annotations, and sometimes custom ones too. The current main way of extending it is to override two large methods (see links in third paragraph).I would find beneficial if there was an isolated method that was responsible for applying bean validations, so that clients could then only overload that. The end result being something similar to how springdoc offers this type of customization functionality.
Currently the annotation -> contraint logic is defined in two locations, depending on whether validation groups are in effect or not. An illustration of this can be seen in the PR that introduces additional validations.
Fixes:
Centralizes the definitions of how a bean validation annotation should affect a schema's constraints into a single location/class. Currently it is defined in two locations, where it is also coupled to the logic that determines whether the constrains should be added or not to the schema (depending on validation groups).
This PR decouples them and places the definitions in a separate component (ValidationAnnotationsUtils) and lets the logic for application then invoke that and ask for the definitions if necessary.
Type of Change
Checklist
Screenshots / Additional Context