[WIP] Upgrade spring-boot-starter from version 2.7.x to 3.3.x #58
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 type
./gradlew build --write-locks
to refresh dependencies)Dependency upgrade: Upgrading spring-boot from version
2.7.+
to3.3.+
NOTE: Please remember to run
./gradlew spotlessApply
to fix any format violations.Changes in this PR
spring-boot-starter-web
andspring-boot-starter-test
from version2.7.+
to3.3.+
.javax
packages tojakarta
packages. See: Spring-Boot-3.0-Migration-Guide#jakarta-eejakarta.validation-api
).@ConstructorBinding
. See: @ConstructingBinding No Longer Needed at the Type LevelNote: Why Apache bVal and not Hibernate Validator or Spring Boot Validator?
A: Firstly, Spring Boot Validator transitively depends on Hibernate Validator, so using either of them provides the same underlying Bean Validation implementation.
The problem with using Hibernate Validator is that it breaks the existing tests.
What I noticed is that
validator.validate(...)
would always raise twice the number of violations. One of which is the actual violation and the other with empty values. I tried to find the cause, and came across a few threads with some not so convincing explanations and workarounds, none of which seemed to work. And after spending a good few hours trying to figure the problem, I still couldn't understand why I was seeing that behavior.In the end, I gave BVal a shot, and it worked fine on the first try. Anyway, BVal supports Bean Validation 3.0, is TCK certified and is being updated frequently. So, I didn't see any reason not to go with it. Also, if we indeed want to use some different implementation in the future; we just have to remove the BVal dependency and add whatever else we want to use.