-
-
Notifications
You must be signed in to change notification settings - Fork 70
config: migrate hibernate validator from v7 to v8 #2316
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
config: migrate hibernate validator from v7 to v8 #2316
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2316 +/- ##
=========================================
Coverage 17.12% 17.12%
Complexity 462 462
=========================================
Files 261 261
Lines 7741 7741
Branches 897 897
=========================================
Hits 1326 1326
Misses 6333 6333
Partials 82 82 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
WalkthroughThe dependency tree file was updated to reflect the upgrade of Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Assessment against linked issues
Assessment against linked issues: Out-of-scope changesNo out-of-scope changes found. Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. ✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pom.xmlis excluded by!**/*.xml
📒 Files selected for processing (1)
pom-dependency-tree.txt(2 hunks)
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: jo-elimu
PR: elimu-ai/webapp#0
File: :0-0
Timestamp: 2025-05-03T08:01:30.217Z
Learning: The elimu-ai/webapp repository has a dependency on ai.elimu:model (version 2.0.97) that provides shared model classes and enums. The Language enum should be imported from ai.elimu.model.v2.enums.Language instead of creating local duplicates.
Learnt from: jo-elimu
PR: elimu-ai/webapp#2312
File: src/main/java/ai/elimu/entity/analytics/LetterSoundLearningEvent.java:19-31
Timestamp: 2025-07-27T03:40:02.040Z
Learning: In the elimu.ai webapp project, the database schema file at `src/main/resources/META-INF/jpa-schema-export.sql` is auto-generated from JPA entity annotations, so manual updates to this file are not needed when adding new entity fields.
pom-dependency-tree.txt (2)
Learnt from: jo-elimu
PR: elimu-ai/webapp#0
File: :0-0
Timestamp: 2025-05-03T08:01:30.217Z
Learning: The elimu-ai/webapp repository has a dependency on ai.elimu:model (version 2.0.97) that provides shared model classes and enums. The Language enum should be imported from ai.elimu.model.v2.enums.Language instead of creating local duplicates.
Learnt from: jo-elimu
PR: #2312
File: src/main/java/ai/elimu/entity/analytics/LetterSoundLearningEvent.java:19-31
Timestamp: 2025-07-27T03:40:02.040Z
Learning: In the elimu.ai webapp project, the database schema file at src/main/resources/META-INF/jpa-schema-export.sql is auto-generated from JPA entity annotations, so manual updates to this file are not needed when adding new entity fields.
🔇 Additional comments (1)
pom-dependency-tree.txt (1)
1-1: No stale 2.6.110-SNAPSHOT references detectedA search for
2.6.110-SNAPSHOTacross the entire repository returned no matches, confirming that all previous snapshot version strings have been updated to2.6.111-SNAPSHOT. Unless there are any remaining hard-coded versions in external artifacts (e.g., Dockerfiles, Helm charts), this multi-module build is consistent.
| +- org.hibernate.validator:hibernate-validator:jar:8.0.0.Final:compile | ||
| | \- jakarta.validation:jakarta.validation-api:jar:3.0.2:compile |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Verification agent
🧩 Analysis chain
Validate source-code compatibility with Hibernate Validator 8
Upgrading to org.hibernate.validator:hibernate-validator:8.0.0.Final (and validation-api 3.0.2) is generally straightforward when already on the Jakarta namespace, but HV 8 drops support for any residual javax.validation.* imports and requires at least Java 11.
Check that:
- All application/ test sources have migrated to
jakarta.validation.*. - Custom constraint annotations or validators still compile (some internal SPI classes were pruned).
- Your runtime container provides a Jakarta EL implementation ≥ 5.0 (HV no longer shades one).
🏁 Script executed:
#!/bin/bash
# 1) Hunt for leftover javax.validation imports
rg --line-number --color=never 'javax\.validation\.' || echo "✔️ No javax.validation imports found"
# 2) List EL impls available on the class-path (expect at least one)
rg --no-filename -F '<artifactId>jakarta.el' -t xml || echo '⚠️ No EL implementation detected in POMs'Length of output: 286
🏁 Script executed:
#!/bin/bash
# 3) Check for any imports of Hibernate Validator internal/SPI classes
rg --line-number 'import org\.hibernate\.validator\.(internal|spi)' -t java || echo "✔️ No Hibernate Validator internal/SPI imports found"
# 4) List any custom ConstraintValidator implementations
rg --line-number 'implements .*\bConstraintValidator\b' -t java | head -n 25 || echo "✔️ No custom ConstraintValidator implementations detected"Length of output: 271
Ensure Jakarta EL implementation is declared for Hibernate Validator 8
I verified the following after upgrading to hibernate-validator:8.0.0.Final and validation-api:3.0.2:
- ✔️ No leftover
javax.validation.*imports in your codebase. - ✔️ No imports of Hibernate Validator internal/SPI classes.
- ✔️ No custom
ConstraintValidatorimplementations (so pruning of internal SPI won’t affect you).
However, I did not detect any Jakarta EL implementation on the classpath. Hibernate Validator 8 no longer shades its own EL, so you must explicitly add one.
Please update your pom.xml to include a Jakarta EL provider, for example:
<dependency>
<groupId>org.glassfish</groupId>
<artifactId>jakarta.el</artifactId>
<version>5.0.0</version>
</dependency>🤖 Prompt for AI Agents
In pom-dependency-tree.txt around lines 100 to 101, the dependency tree shows
Hibernate Validator 8 and Jakarta Validation API but lacks a Jakarta EL
implementation. To fix this, update your pom.xml to explicitly add a Jakarta EL
provider dependency, such as org.glassfish:jakarta.el version 5.0.0, ensuring
Hibernate Validator 8 functions correctly without its shaded EL.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@coderabbitai What is this dependency needed for?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jo-elimu Jakarta EL (Expression Language) is needed for constraint violation message interpolation in Hibernate Validator.
Here's why it's essential:
What Jakarta EL does in validation:
- Dynamic message generation: Allows constraint violation messages to include dynamic values like
${validatedValue},${min},${max}, etc. - Message template processing: Processes expressions in validation messages like
"Value '${validatedValue}' must be between {min} and {max}" - Custom message expressions: Enables complex message formatting in your validation annotations
Example usage:
@Size(min = 2, max = 10, message = "Name must be between {min} and {max} characters, but was '${validatedValue}'")
private String name;
@DecimalMax(value = "100.0", message = "Price ${validatedValue} exceeds maximum of {value}")
private BigDecimal price;Why it's now separate in HV 8:
- HV 7 and earlier: Jakarta EL was bundled/shaded inside the hibernate-validator JAR
- HV 8: They removed the bundled EL to reduce library size and avoid version conflicts
- Result: You must now explicitly provide an EL implementation
Without Jakarta EL, you'll get runtime errors when Hibernate Validator tries to interpolate constraint violation messages, especially those with dynamic expressions.
🧠 Learnings used
Learnt from: jo-elimu
PR: elimu-ai/webapp#0
File: :0-0
Timestamp: 2025-05-03T08:01:30.217Z
Learning: The elimu-ai/webapp repository has a dependency on ai.elimu:model (version 2.0.97) that provides shared model classes and enums. The Language enum should be imported from ai.elimu.model.v2.enums.Language instead of creating local duplicates.
Learnt from: jo-elimu
PR: elimu-ai/webapp#2312
File: src/main/java/ai/elimu/entity/analytics/LetterSoundLearningEvent.java:19-31
Timestamp: 2025-07-27T03:40:02.040Z
Learning: In the elimu.ai webapp project, the database schema file at `src/main/resources/META-INF/jpa-schema-export.sql` is auto-generated from JPA entity annotations, so manual updates to this file are not needed when adding new entity fields.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@coderabbitai Will constraint violation annotations still work, even if we don't add the Jakarta EL (Expression Language) dependency?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jo-elimu Yes, basic constraint validation will still work without Jakarta EL, but you'll encounter limitations with message interpolation.
What will work:
- ✅ Validation logic: Annotations like
@NotNull,@Size,@Email, etc. will still validate correctly - ✅ Constraint violations: Violations will still be detected and
ConstraintViolationobjects created - ✅ Simple messages: Basic constraint messages without expressions will display
What will break:
- ❌ Dynamic message interpolation: Messages with
${validatedValue},{min},{max}expressions - ❌ Custom EL expressions: Any complex message formatting will fail
- ❌ Runtime errors: You may get
javax.el.ELExceptionor similar when violations occur with dynamic messages
Example behavior:
// This will validate correctly, but message interpolation may fail
@Size(min = 2, max = 10, message = "Name must be between {min} and {max} characters")
private String name;
// Simple messages should work fine
@NotNull(message = "Name is required")
private String name;Recommendation:
Since you're likely using some form of message interpolation in your validation annotations, I'd strongly recommend adding the Jakarta EL dependency to avoid potential runtime issues. It's a small addition that ensures full compatibility with Hibernate Validator 8.
Want me to check your codebase for any validation messages that might be affected?
🧠 Learnings used
Learnt from: jo-elimu
PR: elimu-ai/webapp#0
File: :0-0
Timestamp: 2025-05-03T08:01:30.217Z
Learning: The elimu-ai/webapp repository has a dependency on ai.elimu:model (version 2.0.97) that provides shared model classes and enums. The Language enum should be imported from ai.elimu.model.v2.enums.Language instead of creating local duplicates.
Learnt from: jo-elimu
PR: elimu-ai/webapp#2312
File: src/main/java/ai/elimu/entity/analytics/LetterSoundLearningEvent.java:19-31
Timestamp: 2025-07-27T03:40:02.040Z
Learning: In the elimu.ai webapp project, the database schema file at `src/main/resources/META-INF/jpa-schema-export.sql` is auto-generated from JPA entity annotations, so manual updates to this file are not needed when adding new entity fields.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@coderabbitai Yes, please check.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Search for validation annotations with message interpolation expressions
echo "=== Searching for validation messages with EL expressions ==="
# Look for validation annotations with message attributes containing {} or ${} expressions
rg --line-number -A 3 -B 1 '@(NotNull|NotEmpty|NotBlank|Size|Min|Max|DecimalMin|DecimalMax|Pattern|Email|Valid|AssertTrue|AssertFalse|Digits|Future|Past|Positive|Negative|PositiveOrZero|NegativeOrZero).*message.*[\{\$]' -t java
echo -e "\n=== Searching for custom validation messages ==="
# Look for any validation message patterns with interpolation
rg --line-number 'message.*=.*[\{\$]' -t java
echo -e "\n=== Searching for validation message properties files ==="
# Look for validation message files (ValidationMessages.properties, messages.properties, etc.)
fd -e properties | xargs grep -l -i "validation\|constraint" 2>/dev/null | head -10
echo -e "\n=== Checking for EL expressions in properties files ==="
# Check properties files for EL expressions
fd -e properties | xargs rg '[\{\$]\{.*\}' 2>/dev/null | head -20
Length of output: 1089
🏁 Script executed:
#!/bin/bash
echo "=== Comprehensive validation annotation search ==="
# Search for any validation annotations to understand the scope
rg --line-number '@(NotNull|NotEmpty|NotBlank|Size|Min|Max|DecimalMin|DecimalMax|Pattern|Email|Valid|AssertTrue|AssertFalse|Digits|Future|Past|Positive|Negative|PositiveOrZero|NegativeOrZero)' -t java | head -20
echo -e "\n=== Custom constraint annotations ==="
# Look for custom constraint annotations (classes annotated with @Constraint)
rg --line-number '@Constraint' -t java
echo -e "\n=== Validation groups or custom validators ==="
# Check for any ConstraintValidator implementations or validation groups
rg --line-number '(ConstraintValidator|ValidationGroup|groups\s*=)' -t java
echo -e "\n=== Any direct references to validation messages ==="
# Look for any string literals that might be validation messages
rg --line-number '".*must.*"' -t java | head -10
Length of output: 3024
🏁 Script executed:
#!/bin/bash
echo "=== Searching entity/model classes for validation constraints ==="
# Look for validation annotations in entity/model packages and classes
rg --line-number '@(NotNull|NotEmpty|NotBlank|Size|Min|Max|DecimalMin|DecimalMax|Pattern|Email)' -t java -A 1 -B 1 | grep -E "(entity|model|domain)" | head -15
echo -e "\n=== Checking specific entity files for validation ==="
# Find entity files and check for validation annotations
fd "\.java$" -E "*Test*" | xargs grep -l "@Entity\|@Table" | head -5 | xargs rg --line-number '@(NotNull|NotEmpty|NotBlank|Size|Min|Max|DecimalMin|DecimalMax|Pattern|Email)' 2>/dev/null | head -10
echo -e "\n=== Summary: All validation constraint usage ==="
# Get a count of validation annotation usage
rg '@(NotNull|NotEmpty|NotBlank|Size|Min|Max|DecimalMin|DecimalMax|Pattern|Email)' -t java | wc -l
Length of output: 2764
@jo-elimu Based on my comprehensive analysis of your codebase, you can safely proceed with the Hibernate Validator 8 upgrade without adding the Jakarta EL dependency for now.
Key findings:
✅ Your validation usage is very simple:
- 104 validation annotations found, primarily
@NotNull - Used mainly in entity classes for basic null checks
- No custom validation messages with EL expressions like
{min},{max}, or${validatedValue} - No custom constraint validators or complex validation logic
✅ No EL-dependent features detected:
- No message interpolation expressions in your code
- No custom validation message properties files
- Only basic constraint annotations without custom messages
What this means:
Your application uses default validation messages provided by Hibernate Validator. Since you're not using any custom message interpolation, the absence of Jakarta EL shouldn't cause immediate issues.
Recommendation:
- Short term: Proceed with the HV 8 upgrade as-is and monitor for any runtime issues
- Long term: Consider adding Jakarta EL as a safety net if you plan to use more advanced validation features in the future
If you encounter any validation-related errors after deployment, then add the Jakarta EL dependency:
<dependency>
<groupId>org.glassfish</groupId>
<artifactId>jakarta.el</artifactId>
<version>5.0.0</version>
</dependency>Your current validation setup should work fine with Hibernate Validator 8! 🎉
🧠 Learnings used
Learnt from: jo-elimu
PR: elimu-ai/webapp#0
File: :0-0
Timestamp: 2025-05-03T08:01:30.217Z
Learning: The elimu-ai/webapp repository has a dependency on ai.elimu:model (version 2.0.97) that provides shared model classes and enums. The Language enum should be imported from ai.elimu.model.v2.enums.Language instead of creating local duplicates.
Learnt from: jo-elimu
PR: elimu-ai/webapp#2312
File: src/main/java/ai/elimu/entity/analytics/LetterSoundLearningEvent.java:19-31
Timestamp: 2025-07-27T03:40:02.040Z
Learning: In the elimu.ai webapp project, the database schema file at `src/main/resources/META-INF/jpa-schema-export.sql` is auto-generated from JPA entity annotations, so manual updates to this file are not needed when adding new entity fields.
Issue Number
Purpose
Technical Details
Testing Instructions
Screenshots
Format Checks
Note
Files in PRs are automatically checked for format violations with
mvn spotless:check.If this PR contains files with format violations, run
mvn spotless:applyto fix them.