Develop Reference

Add custom validation message to enum

Is it possible to add a custom message to an enum if validation fails?
I have this enum class:
public enum EngineType{
FOO('F'),
BAR('B'),
QUX('Q');
private char id;
EngineType(char id) {
this.id = id;
}
public char getId() {
return this.id;
}
}
My model class contains private MyEnum myEnum;.
Currently if a value is passed in which isn't a valid enum, I get this BindingException:
{
"status": 400,
"validationErrors": {
"myEnum": "Failed to convert property value of type 'java.lang.String' to required type 'ie.aviva.services.motor.cartellservice.model.EngineType' for property 'myEnum'; nested exception is org.springframework.core.convert.ConversionFailedException: Failed to convert from type [java.lang.String] to type [#javax.validation.constraints.NotNull ie.aviva.services.motor.cartellservice.model.EngineType] for value 'corge';"
},
"title": "Bad Request"
}
My controller looks like this:
#RequestMapping(
method = RequestMethod.GET,
value = Endpoints.TRUE_MATCH,
produces = {"application/json"})
public ResponseEntity<ResponseWrapper<List<TrueMatch>>> getTrueMatch(
#Valid MyDetails MyDetails) {
LogContext.put(Constants.TAG, myDetails);
LOG.info(
"Controller called to get true match with my details: " + myDetails.toString());
...
}
MyDetails is like this:
#NoArgsConstructor
#AllArgsConstructor
#Getter
#Setter
#SuperBuilder
public class MyDetails extends BasicDetails {
#NotBlank
#Pattern(
regexp = "^[a-zA-Z]*$",
message = "'${validatedValue}' contains unsupported characters")
private String name;
#NotNull private MyEnum myEnum;
...
}
Is it possible to change the message to some custom message of my own?
I'm already able to do this in annotations that I added to other variables by including the message parameter in the annotation. I tried creating an annotation to validate the pattern as seen here but it didn't work. I think because the annotation was added like this, which was too late. The exception had already been thrown:
#NotNull
#EnumNamePattern(regexp = "foo|bar|qux")
private MyEnum myEnum;

Sure. The simplistic solution would be to simply accept the value as a String, then wrap your parsing logic in a try-catch block, then return the result you want the user to see.
final MyEnum userValue;
try
{
userValue = MyEnum.valueOf(someStringInput);
}
catch (Exception e)
{
//respond to the user, either with an exception, or
//a proper response according to your application
}

Bean Validation & ControllerAdvice
You can make use of the Bean Validation and Exception-handling mechanisms provided by spring.
Note that OP is already using Bean validation in their project, which can be observed by the usage of annotations #NotBlank, #Pattern. So the following reference is exclusively for the Readers.
To include the Bean validation into your Spring Boot project, you can add Spring Boot Starter Validation dependency. In a nutshell, Bean validation is a specification (like for instance JPA) describing an IPA, which offers various annotations and interfaces for verifying that the data of domain objects is correct. And Hibernate Validator is an implementation of this specification which comes with Spring Boot Starter Validation.
To validate that the given String matches one of the enum-constants we would need a separate class, let's say MyDetailsDto. In case if you wonder why a new class? If the validation constant would be applied on the field of type enum it would validate only input that can be successfully parsed into an enum (otherwise an IllegalArgumentException would be thrown before applying the validation annotation), which can be useful only certain enum-constants can be assigned to a field. But that's not the case, we need to find out whether the given string is equal to one of the enum constants (by the way, in addition this approach creates an opportunity for sanitizing the input, for instance replacing some characters if needed).
#Getter
#Setter
public class MyDetailsDto {
private String name;
#EngineTypeConstraint
private String engineType;
public MyDetails toMyDetails() {
return new MyDetails(name, EngineType.valueOf(engineType));
}
}
So, to create a custom Validation constraint, we need two things: a custom annotation a Validator associated with it (for more information refer to the documentation - Configuring Custom Constraints):
Each bean validation constraint consists of two parts:
A #Constraint annotation that declares the constraint and its configurable properties.
An implementation of the jakarta.validation.ConstraintValidator interface that implements the constraint’s behavior.
We can find more information regarding the requirements for the custom annotation in the Bean validation documentation Constraint:
Each constraint annotation must host the following attributes:
String message() default [...]; which should default to an error
message key made of the fully-qualified class name of the constraint
followed by .message. For example
"{com.acme.constraints.NotSafe.message}"
Class<?>[] groups() default {}; for user to customize the targeted groups
Class<? extends Payload>[] payload() default {}; for extensibility purposes
So our custom annotation needs to have at least these three attributes, and we're interested primarily in the first one, providing a message which would be used in case if an exception occurs. Let's our annotation:
#Constraint(validatedBy = EngineTypeValidator.class)
#Documented
#Target({ElementType.METHOD, ElementType.FIELD})
#Retention(RetentionPolicy.RUNTIME)
public #interface EngineTypeConstraint {
String message() default "Engine type does not exist";
Class<?>[] groups() default {};
Class<? extends Payload>[] payload() default {};
}
Validator should implement generic interface ConstraintValidator, specifying the associated annotation and the validated type as its parameters.
That's how the implementation might look like:
public class EngineTypeValidator implements ConstraintValidator<EngineTypeConstraint, String> {
private static final Set<String> TYPE_NAMES =
EnumSet.allOf(EngineType.class).stream().map(Enum::name).collect(Collectors.toSet());
#Override
public boolean isValid(String engineType,
ConstraintValidatorContext constraintValidatorContext) {
if (!TYPE_NAMES.contains(engineType)) throw new EngineTypeNotValidException(engineType);
return true;
}
}
As you have probably noticed, validator throws a custom exception EngineTypeNotValidException which receives an invalid engine model as a parameter. We need this exception in order to build a response based on it.
public class EngineTypeNotValidException extends RuntimeException {
public EngineTypeNotValidException(String type) {
super(String.format("Engine type '%s' doesn't exist.", type));
}
}
To handle this exception and produces an error-response by using Controller Advice. For that, we need to define a class annotated with #ControllerAdvice and create a method marked with #ExceptionHandler to target the custom exception defined above.
#ControllerAdvice(assignableTypes = MyDetailsController.class)
public class ValidationExceptionHandler {
#ExceptionHandler(EngineTypeNotValidException.class)
public ResponseEntity<ErrorResponse> handleInvalidEngine(RuntimeException e) {
Throwable cause = e.getCause();
return ResponseEntity
.badRequest()
.body(new ErrorResponse(
HttpStatus.BAD_REQUEST.value(),
HttpStatus.BAD_REQUEST.getReasonPhrase(),
List.of(cause.getMessage())
));
}
}
Finally, to customize the response body, we can create a POJO with a couple of string field for representing the information of a failing response.
#AllArgsConstructor
#Getter
public class ErrorResponse {
private int status;
private String message;
private List<String> errors;
}
Demo
That's it now we can give it a try.
Consider the following dummy Controller:
#RestController
public class MyDetailsController {
#PostMapping("/newMyDetails")
public String newCar(#RequestBody #Valid MyDetailsDto dto) {
// some business logic
return "is valid";
}
}
And here's a couple screenshots from Postman with responses:
Valid request (hard-coded message from the Controller in the response):
Invalid request (response with a customized error message, prompting that enum-name provided in the request doesn't exist):

Conditional Validating Request with SpringBoot

I am using Spring-WebMvc and SpringBoot in constructing a web service, together with spring-boot-starter-validation to simplify the setup.
In the new user requirement, validation needs to be done conditionally based on user request, which I am not sure how the design could fit well.
Below is an example, where such conditional checking is needed. Hope one can give a direction / solution on how can one do it in a better way.
Example
Let's say we are creating a service for multiple organizations and we are using one server to handle different organization request. Each organization request must supply a valid companyId to identify the organization.
And at the beginning, all organizations are strictly forbidding its own employee to place a lucky draw request.
public class Request {
#CompanyId
private String companyId;
}
#StaffNotAllowLuckyDraw
public class LuckyDrawRequest extends Request {
private String userId;
}
With the corresponding annotation and validator.
#Retention(RetentionPolicy.RUNTIME)
#Target({ ElementType.TYPE, ElementType.ANNOTATION_TYPE })
#Constraint(validatedBy = { StaffNotAllowLuckyDrawValidator.class })
public #interface StaffNotAllowLuckyDraw {
String message() default "{com.abc.validation.constraints.staffnotallowluckydraw.message}";
Class<?>[] groups() default {};
Class<? extends Payload>[] payload() default {};
}
public class StaffNotAllowLuckyDrawValidator implements ConstraintValidator<StaffNotAllowLuckyDraw, LuckyDrawRequest> {
#Override
public boolean isValid(LuckyDrawRequest request, ConstraintValidatorContext context) {
String companyId = request.getCompanyId();
String userId = request.getUserId();
User user = Database.getUser(companyId, userId);
return !user.isStaff();
}
}
But later,
a new requirement comes, which allow company to customize the validation, allowing / forbidding a staff to place a lucky draw request.
So the validator logic needs to be changed.
And definitely I can add custom logic inside this validator to make it work very easily. Like below.
public class StaffNotAllowLuckyDrawValidator implements ConstraintValidator<StaffNotAllowLuckyDraw, LuckyDrawRequest> {
private List<String> exceptions;
#Override
public boolean isValid(LuckyDrawRequest request, ConstraintValidatorContext context) {
String companyId = request.getCompanyId();
if (exceptions.contains(companyId)) {
return true;
}
String userId = request.getUserId();
User user = Database.getUser(companyId, userId);
return !user.isStaff();
}
}
However, it seems unclear to me from the Annotation perspective (look at LuckyDrawRequest class) that there are such condition to skip such validation.
Worse still, there may have more and more such custom validation coming, and some maybe using default validation (e.g. #Max) Is there any approach to handle the above problem?
Note that the validation message should not be changed, on this change. As it has been used for months already.
P.S.
I am using spring-boot#2.5.3, which includes hibernate-validator#6.2.0, which should be JSR380 compliance.

Dynamic POJO validation based on groups in spring

Consider the following pojo for reference:
public class User{
private String username;
private String firstName;
private String middleName;
private String lastName;
private String phone;
//getters and setters
}
My application is a basically spring-boot based REST API which exposes two endpoints, one to create the user and the other to retrieve a user.
The "users" fall into certain categories, group-a, group-b etc. which I get from the headers of the post request.
I need to validated the user data in runtime and the validations may differ based on the group of a user.
for example, the users that fall into group-a may have phone numbers as an optional field whereas it might be a mandatory field for some other group.
The regex may also vary based on their groups.
I need to be able to configure spring, to somehow dynamically validate my pojo as soon as they are created and their respective set of validations get triggered based on their groups.
Maybe I can create a yml/xml configuration which would allow me to enable this?
I would prefer to not annotate my private String phone with #NotNull and #Pattern.
My configuration is as follows:
public class NotNullValidator implements Validator {
private String group;
private Object target;
public String getGroup() {
return group;
}
public void setGroup(String group) {
this.group = group;
}
public Object getTarget() {
return target;
}
public void setTarget(Object target) {
this.target = target;
}
#Override
public void validate(Object o) {
if (Objects.nonNull(o)) {
throw new RuntimeException("Target is null");
}
}
}
public interface Validator {
void validate(Object o);
}
#ConfigurationProperties(prefix = "not-null")
#Component
public class NotNullValidators {
List<NotNullValidator> validators;
public List<NotNullValidator> getValidators() {
return validators;
}
public void setValidators(List<NotNullValidator> validators) {
this.validators = validators;
}
}
application.yml
not-null:
validators:
-
group: group-a
target: user.username
-
group: group-b
target: user.phone
I want to configure my application to somehow allow the validators to pick their targets (the actual objects, not the strings mentioned in the yml), and invoke their respective public void validate(Object o) on their targets.
P.S.
Please feel free to edit the question to make it better.
I am using jackson for serializing and deserializing JSON.

The easiest solution to your problem, as i see it, is not with Spring or the POJOs themselves but with a design pattern.
The problem you're describing is easily solved by a strategy pattern solution.
You match the strategy to use by the header you're expecting in the request, that describes the type of user, and then you perform said validations inside the strategy itself.
This will allow you to use the same POJO for the whole approach, and deal with the specifics of handling/parsing and validating data according to the each type of user's strategy.
Here's a link from wiki books with a detailed explanation of the pattern
Strategy Pattern
Suppose you have a basic interface for your strategies:
interface Strategy {
boolean validate(User user);
}
And you have 2 different implementations for the 2 different types of user:
public class StrategyA implements Strategy {
public boolean validate(User user){
return user.getUsername().isEmpty();
}
}
public class StrategyB implements Strategy {
public boolean validate(User user){
return user.getPhone().isEmpty();
}
}
You add a Strategy attribute to your User POJO and assign the right implementation of the Strategy to that attribute when you receive the post request.
Everytime you need to validate data for that user you just have to invoke the validate method of the assigned strategy.
If each User can fit multiple strategies, you can add a List<Strategy> as an attribute instead of a single one.
If you don't want to change the POJO you have to check which is the correct strategy every time you receive a post request.
Besides the validate method you can add methods to handle data, specific to each strategy.
Hope this helps.

You can use validation groups to control which type of user which field gets validated for. For example:
#NotBlank(groups = {GroupB.class})
private String phone;
#NotBlank(groups = {GroupA.class, GroupB.class})
private String username;
Then you use the headers from the request that you mentioned to decide which group to validate against.
See http://blog.codeleak.pl/2014/08/validation-groups-in-spring-mvc.html?m=1 for a complete example.
Updated to include a more comprehensive example:
public class Val {
private Validator validator = Validation.buildDefaultValidatorFactory().getValidator();
public boolean isValid(User user, String userType) {
usergroups userGroup = usergroups.valueOf(userType);
Set<ConstraintViolation<User>> constraintViolations = validator.validate(user, userGroup.getValidationClass());
return constraintViolations.isEmpty();
}
public interface GroupA {}
public interface GroupB {}
public enum usergroups {
a(GroupA.class),
b(GroupB.class);
private final Class clazz;
usergroups(Class clazz) {
this.clazz = clazz;
}
public Class getValidationClass() {
return clazz;
}
}
}
This doesn't use application.yaml, instead the mapping of which fields are validated for each group is set in annotations, similar results using Spring's built in validation support.

I was able to solve my problem with the use of Jayway JsonPath.
My solution goes as follows:
Add a filter to your API which has the capability to cache the InputStream of the ServletRequest since it can be read only once. To achieve this, follow this link.
Create a bunch of validators and configure them in your application.yml file with the help of #ConfigurationProperties. To achieve this, follow this link
Create a wrapper which would contain all your validators as a list and initialize it with #ConfigurationProperties and the following configuration:
validators:
regexValidators:
-
target: $.userProfile.lastName
pattern: '[A-Za-z]{0,12}'
group: group-b
minMaxValidators:
-
target: $.userProfile.age
min: 18
max: 50
group: group-b
Call the validate method in this wrapper with the group which comes in the header, and then call the validate of the individual validators. To achieve this, I wrote the following piece of code in my wrapper:
public void validate(String input, String group) {
regexValidators.stream()
.filter(validator -> group.equals(validator.getGroup()))
.forEach(validator -> validator.validate(input));
minMaxValidators.stream()
.filter(validator -> group.equals(validator.getGroup()))
.forEach(validator -> validator.validate(input));
}
and the following method in my validator:
public void validate(String input) {
String data = JsonPath.parse(input).read(target);
if (data == null) {
throw new ValidationException("Target: " + target + " is NULL");
}
Matcher matcher = rule.matcher(data);
if (!matcher.matches()) {
throw new ValidationException("Target: " + target + " does not match the pattern: " + pattern);
}
}
I have created a functioning project to demonstrate the validations and it can be found here.
I understand that the answer alone might not be very clear, please follow the above mentioned url for the complete source code.

jOOQ: Allowed-Character constraints?

I am considering moving from Hibernate to jOOQ but I can't find e.g.
how to have Pattern-Constraints on a String like this in Hibernate:
#NotEmpty(message = "Firstname cannot be empty")
#Pattern(regexp = "^[a-zA-Z0-9_]*$", message = "First Name can only contain characters.")
private String firstname;
How would I do that in jOOQ?

The "jOOQ way"
The "jOOQ way" to do such validation would be to create either:
A CHECK constraint in the database.
A trigger in the database.
A domain in the database.
After all, if you want to ensure data integrity, the database is where such constraints and integrity checks belong (possibly in addition to functionally equivalent client-side validation). Imagine a batch job, a Perl script, or even a JDBC statement that bypasses JSR-303 validation. You'll find yourself with corrupt data in no time.
If you do want to implement client-side validation, you can still use JSR-303 on your DTOs, which interact with your UI, for instance. But you will have to perform validation before passing the data to jOOQ for storage (as artbristol explained).
Using a Converter
You could, however, use your own custom type by declaring a Converter on individual columns and by registering such Converter with the source code generator.
Essentially, a Converter is:
public interface Converter<T, U> extends Serializable {
U from(T databaseObject);
T to(U userObject);
Class<T> fromType();
Class<U> toType();
}
In your case, you could implement your annotations as such:
public class NotEmptyAlphaNumericValidator implements Converter<String, String> {
// Validation
public String to(String userObject) {
assertNotEmpty(userObject);
assertMatches(userObject, "^[a-zA-Z0-9_]*$");
return userObject;
}
// Boilerplate
public String from(String databaseObject) { return databaseObject; }
public Class<String> fromType() { return String.class; }
public Class<String> toType() { return String.class; }
}
Note that this is more of a workaround, as Converter hasn't been designed for this use-case, even if it can perfectly implement it.
Using formal client-side validation
There's also a pending feature request #4543 to add more support for client-side validation. As of jOOQ 3.7, this is not yet implemented.

I recommend you don't try to use jOOQ in a 'hibernate/JPA' way. Leave the jOOQ generated classes as they are and map to your own domain classes manually, which you are free to annotate however you like. You can then call a JSR validator before you attempt to persist them.
For example, jOOQ might generate the following class
public class BookRecord extends UpdatableRecordImpl<BookRecord> {
private String firstname;
public void setId(Integer value) { /* ... */ }
public Integer getId() { /* ... */ }
}
You can create your own domain object
public class Book {
#NotEmpty(message = "Firstname cannot be empty")
#Pattern(regexp = "^[a-zA-Z0-9_]*$", message = "First Name can only contain characters.")
private String firstname;
public void setId(Integer value) { /* ... */ }
public Integer getId() { /* ... */ }
}
and map by hand once you've retrieved a BookRecord, in your DAO layer
Book book = new Book();
book.setId(bookRecord.getId());
book.setFirstname(bookRecord.getFirstname());
This seems quite tedious (and ORM tries to spare you this tedium) but actually it scales quite well to complicated domain objects, in my opinion, and it's always easy to figure out the flow of data in your application.

Assign custom identifier to an #id property

I'm migrating a legacy system over to use Hibernate 3. It currently generates its own identifiers. To keep with what the system currently does before I try and move it over to something a little better, how would I go about specifying (using annotations) my own class that will return the custom generated identifiers when an insert occurs?
Something like:
#Id
#CustomIdGenerator(Foo.class) // obviously this is not a real annotation
public String getId() { ... }
Where the Foo class has one method that generates the identifier.
Currently I'm just calling the setId(String id) method manually but was hoping for a better way to deal with this situation.

I don't think there is out-of-box support for generating custom Ids using custom annotations using pure JPA-2 API. But if you want to use provider specific API, then the job is pretty simple. Sample Example
To be provider independent try any of following tricks....
IdGeneratorHolder
public abstract class IdGeneratorHolder {
/* PersistentEntity is a marker interface */
public static IdGenerator getIdGenerator(Class<? extends PersistentEntity> entityType) {
/* sample impelementation */
if(Product.class.isAssignableFrom(entityType)) {
return new ProductIdGenerator();
}
return null;
}
}
General IdGenerator interface
public interface IdGenerator {
String generate();
}
Specific IdGenerator - Product Id Generator
public class ProductIdGenerator implements IdGenerator {
public String generate() {
/* some complicated logic goes here */
return ${generatedId};
}
}
Now set the generated id either in no-arg constructor OR in #PrePersist method.
Product.java
public class Product implements PersistentEntity {
private String id;
public Product() {
id = IdGeneratorHolder.getIdGenerator(getClass()).generate();
}
#PrePersist
public void generateId() {
id = IdGeneratorHolder.getIdGenerator(getClass()).generate();
}
}
In above example all the ids are of the same type i.e. java.lang.String. If the persistent entities have ids of different types.....
IdGenerator.java
public interface IdGenerator {
CustomId generate();
}
CustomId.java
public class CustomId {
private Object id;
public CustomId(Object id) {
this.id = id;
}
public String toString() {
return id.toString();
}
public Long toLong() {
return Long.valueOf(id.toString());
}
}
Item.java
#PrePersist
public void generateId() {
id = IdGeneratorHolder.getIdGenerator(getClass()).generate().toLong();
}
You can also use your custom annotation...
CustomIdGenerator.java
public #interface CustomIdGenerator {
IdStrategy strategy();
}
IdStrategy.java
enum IdStrategy {
uuid, humanReadable,
}
IdGeneratorHolder.java
public abstract class IdGeneratorHolder {
public static IdGenerator getIdGenerator(Class<? extends PersistentEntity> entityType) {
try { // again sample implementation
Method method = entityType.getMethod("idMethod");
CustomIdGenerator gen = method.getAnnotation(CustomIdGenerator.class);
IdStrategy strategy = gen.strategy();
return new ProductIdGenerator(strategy);
}
One more thing.... If we set id in #PrePersist method, the equals() method cannot rely on id field (i.e. surrogate key), we have to use business/natural key to implement equals() method. But if we set id field to some unique value (uuid or "app-uid" unique within application) in no-arg constructor, it helps us to implement the equals() method.
public boolean equals(Object obj) {
if(obj instanceof Product) {
Product that = (Product) obj;
return this.id ==that.id;
}
return false;
}
If we or someone else call (intentionally or by mistake) the #PrePersist annotated method more than one times, the "unique id will be changed!!!" So setting id in no-arg constructor is preferable. OR to address this issue put a not null check...
#PrePersist
public void generateId() {
if(id != null)
id = IdGeneratorHolder.getIdGenerator(getClass()).generate();
}
}
UPDATE
If we put the id generation in a
no-arg constructor, wouldn't that
cause a problem when loading entities
from the database? because hibernate
will call the no-arg constructor
causing existing ids to be
re-generated
Yeah you are right, I missed that part. :( Actually, I wanted to tell you that:- in my application every Entity object is associated with an Organization Entity; so I've created an abstract super class with two constructors, and every Entity (except Organization) extends this class.
protected PersistentEntityImpl() {
}
protected PersistentEntityImpl(Organization organization) {
String entityId = UUIDGenerator.generate();
String organizationId = organization.getEntityId();
identifier = new EntityIdentifier(entityId, organizationId);
}
The no-arg constructor is for JPA provider, we never invoke no-arg constructor, but the other organization based constructor. As you can see. id is assigned in Organization based constructor. (I really missed this point while writing the answer, sorry for that).
See if you can implement this or similar strategy in your application.
The second option was using the
#PrePersist annotation. I put that in
and the method never got hit and gave
me an exception stating that I needed
to set the id manually. Is there
something else I should be doing?
Ideally, JPA provider should invoke #PrePersist methods (one declared in class and also all the other methods that are declared in super-classes) before persisting the entity object. Can't tell you what is wrong, unless you show some code and console.

You can.
First, implement org.hibernate.id.IdentifierGenerator
Then you'd have to map it in a mapping xml file. I couldn't find a way to do this with annotations:
<!--
<identifier-generator.../> allows customized short-naming
of IdentifierGenerator implementations.
-->
<!ELEMENT identifier-generator EMPTY>
<!ATTLIST identifier-generator name CDATA #REQUIRED>
<!ATTLIST identifier-generator class CDATA #REQUIRED>
Finally, use #GeneratedValue(generator="identifier-name")
Note that this is hibernate-specific (not JPA)
Update: I took a look at the sources of Hibernate, and it seems at one place, after failing to resolve the short name, hibernates attempts to call Class.forName(..). The parameter there is called strategy. So Here's what you try:
try setting the class fully-qualified name as string in the generator attribute
try setting the class fqn as string in the #GenericGenerator strategy attribute (with some arbitrary name)
Let me know which (if any) worked