Develop Reference

How to get query parameter name from ConstraintViolationException

I have a service method:
#GetMapping(path = "/api/some/path", produces = MediaType.APPLICATION_JSON_VALUE)
public ResponseEntity<?> getWhatever(#RequestParam(value = "page-number", defaultValue = "0") #Min(0) Integer pageNumber, ...
If the caller of an API doesn't submit a proper value for page-number query parameter, javax.ConstraintViolationexception is being raised. The message of the exception would read smth like:
getWhatever.pageNumber must be equal or greater than 0
In the response body, I would like to have this message instead:
page-number must be equal or greater than 0
I want my message to have the name of a query parameter, not the name of the argument. IMHO, including the name of the argument is exposing the implementation details.
The problem is, I cannot find an object that is carrying query parameter name. Seems like the ConstraintViolationException doesn't have it.
I am running my app in spring-boot.
Any help would be appreciated.
P.S.: I have been to the other similar threads that claim to solve the problem, none of them actually do in reality.

Here is how I made it work in spring-boot 2.0.3:
I had to override and disable ValidationAutoConfiguration in spring-boot:
import org.springframework.boot.validation.MessageInterpolatorFactory;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Lazy;
import org.springframework.core.env.Environment;
import org.springframework.validation.beanvalidation.LocalValidatorFactoryBean;
import org.springframework.validation.beanvalidation.MethodValidationPostProcessor;
import javax.validation.Validator;
#Configuration
public class ValidationConfiguration {
public ValidationConfiguration() {
}
#Bean
public static LocalValidatorFactoryBean validator() {
LocalValidatorFactoryBean factoryBean = new LocalValidatorFactoryBean();
factoryBean.setParameterNameDiscoverer(new CustomParamNamesDiscoverer());
MessageInterpolatorFactory interpolatorFactory = new MessageInterpolatorFactory();
factoryBean.setMessageInterpolator(interpolatorFactory.getObject());
return factoryBean;
}
#Bean
public static MethodValidationPostProcessor methodValidationPostProcessor(Environment environment, #Lazy Validator validator) {
MethodValidationPostProcessor processor = new MethodValidationPostProcessor();
boolean proxyTargetClass = (Boolean) environment.getProperty("spring.aop.proxy-target-class", Boolean.class, true);
processor.setProxyTargetClass(proxyTargetClass);
processor.setValidator(validator);
return processor;
}
}
CustomParamNamesDiscoverer sits in the same package and it is a pretty much a copy-paste of DefaultParameterNameDiscoverer, spring-boot's default implementation of param name discoverer:
import org.springframework.core.*;
import org.springframework.util.ClassUtils;
public class CustomParameterNameDiscoverer extends PrioritizedParameterNameDiscoverer {
private static final boolean kotlinPresent = ClassUtils.isPresent("kotlin.Unit", CustomParameterNameDiscoverer.class.getClassLoader());
public CustomParameterNameDiscoverer() {
if (kotlinPresent) {
this.addDiscoverer(new KotlinReflectionParameterNameDiscoverer());
}
this.addDiscoverer(new ReqParamNamesDiscoverer());
this.addDiscoverer(new StandardReflectionParameterNameDiscoverer());
this.addDiscoverer(new LocalVariableTableParameterNameDiscoverer());
}
}
I wanted it to remain pretty much intact (you can see even kotlin checks in there) with the only addition:
I am adding an instance of ReqParamNamesDiscoverer to the linked lists of discoverers. Note that the order of addition does matter here.
Here is the source code:
import com.google.common.base.Strings;
import org.springframework.core.ParameterNameDiscoverer;
import org.springframework.lang.Nullable;
import org.springframework.web.bind.annotation.RequestParam;
import java.lang.reflect.Constructor;
import java.lang.reflect.Executable;
import java.lang.reflect.Method;
import java.lang.reflect.Parameter;
public class ReqParamNamesDiscoverer implements ParameterNameDiscoverer {
public ReqParamNamesDiscoverer() {
}
#Override
#Nullable
public String[] getParameterNames(Method method) {
return doGetParameterNames(method);
}
#Override
#Nullable
public String[] getParameterNames(Constructor<?> constructor) {
return doGetParameterNames(constructor);
}
#Nullable
private static String[] doGetParameterNames(Executable executable) {
Parameter[] parameters = executable.getParameters();
String[] parameterNames = new String[parameters.length];
for (int i = 0; i < parameters.length; ++i) {
Parameter param = parameters[i];
if (!param.isNamePresent()) {
return null;
}
String paramName = param.getName();
if (param.isAnnotationPresent(RequestParam.class)) {
RequestParam requestParamAnnotation = param.getAnnotation(RequestParam.class);
if (!Strings.isNullOrEmpty(requestParamAnnotation.value())) {
paramName = requestParamAnnotation.value();
}
}
parameterNames[i] = paramName;
}
return parameterNames;
}
}
If parameter is annotated with RequestParam annotation, I am retrieving the value attribute and return it as a parameter name.
The next thing was disabling auto validation config, somehow, it doesn't work without it. This annotation does the trick though:
#SpringBootApplication(exclude = {ValidationAutoConfiguration.class})
Also, you need to have a custom handler for your ConstraintValidationException :
#ResponseStatus(HttpStatus.BAD_REQUEST)
#ExceptionHandler(ConstraintViolationException.class)
public ErrorDTO handleConstraintViolationException(ConstraintViolationException ex) {
Map<String, Collection<String>> errors = new LinkedHashMap<>();
ex.getConstraintViolations().forEach(constraintViolation -> {
String queryParamPath = constraintViolation.getPropertyPath().toString();
log.debug("queryParamPath = {}", queryParamPath);
String queryParam = queryParamPath.contains(".") ?
queryParamPath.substring(queryParamPath.indexOf(".") + 1) :
queryParamPath;
String errorMessage = constraintViolation.getMessage();
Collection<String> perQueryParamErrors = errors.getOrDefault(queryParam, new ArrayList<>());
perQueryParamErrors.add(errorMessage);
errors.put(queryParam, perQueryParamErrors);
});
return validationException(new ValidationException("queryParameter", errors));
}
ValidationException stuff is my custom way of dealing with validation errors, in a nutshell, it produces an error DTO, which will be serialized into JSON with all the validation error messages.

Add a custom message to #Min annotation like this
#Min(value=0, message="page-number must be equal or greater than {value}")

Right now, you cannot do it (well, except if you define a custom message for each annotation but I suppose that's not what you want).
Funnily enough, someone worked recently on something very similar: https://github.com/hibernate/hibernate-validator/pull/1029 .
This work has been merged to the master branch but I haven't released a new 6.1 alpha containing this work yet. It's a matter of days.
That being said, we had properties in mind and now that you ask that, we should probably generalize that to more things, method parameters included.
Now that we have the general idea, it shouldn't be too much work to generalize it, I think.
I'll discuss this with the contributor and the rest of the team and get back to you.

I don't think getting the name of the query parameter is possible but would like to be proven wrong if somebody knows a way.
As Dmitry Bogdanovich says, having a custom message is the easiest and only way I know how to do something close to what you need. If you say you don't want to clutter your code with these messages, you can just do this:
Add a ValidationMessages.properties file in your resources folder. Here you can just say:
page_number.min=page-number must be equal or greater than {value}
Now you can use the annotation and write:
#Min(value = 0, message = "{page_number.min}")
This way you have a single source to change anything about the message when needed.

Alternative Annotations to Java Bean Validation Without Using Hibernate

I am working on a project that I need to put some limitations/constrains on the fields of the models(e.g. "String name" field should not exceed 10 characters) . I can only find Java Bean Validation API for this job. However as I see, it is used with Hibernate and Spring Framework.
Unfortunately, an ORM like Hibernate was not used in the project. We are using DAO pattern and JDBI for database operations.
Is there any alternative annotations on Java which helps to put constrains on the fields like Bean Validation does( and hopefully works with magic like Lombok does)? I need basically Size, Min/Max and NonNull annotations.
Basically something like this:
class User {
#Size(max = 10)
String name;
}

karelss already answered, you can also use javax.validation.constraints package here maven link. Here is possible implementation and test code (not perfect one).
User.java
import javax.validation.constraints.Size;
class User {
#Size(max = 10)
String name;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
UserTest.java
import static org.junit.Assert.assertEquals;
import java.util.Set;
import javax.validation.ConstraintViolation;
import javax.validation.Validation;
import javax.validation.Validator;
import javax.validation.ValidatorFactory;
import org.junit.Test;
public class UserTest {
#Test
public void test() {
User user = new User();
// set name over 10
user.setName("12345678912");
// validate the input
ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
Validator validator = factory.getValidator();
Set<ConstraintViolation<User>> violations = validator.validate(user);
for (ConstraintViolation v : violations) {
String key = "";
if (v.getPropertyPath() != null) {
key = v.getPropertyPath().toString();
assertEquals("name", key);
assertEquals("size must be between 0 and 10", v.getMessage());
}
}
assertEquals(1, violations.size());
}
}

Java Bean Validation API is the right tool for this job, but as you say is an api, if you are using an application server, you will have different implementations and you can use whatever you want, it's not linked to hibernate or spring, what you see are different providers of the api implementatión. This api works with objects, you can annotate any object with it.
If you don't want to include dependencies you can implement this validations in a compatible way using your own annotations like here
Java 7 Bean validation API

How to add JSR 303 validation to arguments of a method

I would like to use Hibernate Validator to validate arguments of my method.
I have tried to look-up examples and went through the following example
JSR 303. Validate method parameter and throw exception
But the answer does not exactly solve my problem and also the links are expired in the answer.
Here is a sample code of what I have tried.
//removing imports to reduce the length of code.
/**
* Created by Nick on 15/06/2016.
*/
#Component
public class ValidationService {
#Value("${namesAllowed}")
private String validNames;
#Autowired
private Validator validator;
public boolean validateName(
#NotEmpty
#Pattern(regexp = ".*'.*'.*")
#Email
#Length(max = 10)
String name
) {
Set<ConstraintViolation<String>> violations = validator.validate(name);
for (ConstraintViolation<String> violation : violations) {
String propertyPath = violation.getPropertyPath().toString();
String message = violation.getMessage();
System.out.println("invalid value for: '" + propertyPath + "': " + message);
}
List<String> namesAllowed= Arrays.asList(validNames.split(","));
if (namesAllowed.contains(name.substring(name.indexOf(".") + 1))) {
return true;
}
return false;
}
}
}

Method validation has been standardized as part of Bean Validation 1.1. You can learn more about it in the Hibernate Validator reference guide.
With Spring you need to configure a MethodValidationPostProcessor bean and annotate the constrained class with #Validated. Also this answer may be helpful to you.

Preventing 'PersistentObjectException'

I have a very basic JAX-RS service (the BookService class below) which allows for the creation of entities of type Book (also below). POSTing the payload
{
"acquisitionDate": 1418849700000,
"name": "Funny Title",
"numberOfPages": 100
}
successfully persists the Book and returns 201 CREATED. However, including an id attribute with whichever non-null value on the payload triggers an org.hibernate.PersistentObjectException with the message detached entity passed to persist. I understand what this means, and including an id on the payload when creating an object (in this case) makes no sense. However, I'd prefer to prevent this exception from bubbling all the way up and present my users with, for instance, a 400 BAD REQUEST in this case (or, at least, ignore the attribute altogether). However, there are two main concerns:
The exception that arrives at create is an EJBTransactionRolledbackException and I'd have to crawl all the way down the stack trace to discover the root cause;
The root cause is org.hibernate.PersistentObjectException - I'm deploying to Wildfly which uses Hibernate, but I want to maintain my code portable, so I don't really want to catch this specific exception.
To my understanding, there are two possible solutions:
Use book.setId(null) before bookRepo.create(book). This would ignore the fact that the id attribute carries a value and proceed with the request.
Check if book.getId() != null and throw something like IllegalArgumentException that could be mapped to a 400 status code. Seems the preferable solution.
However, coming from other frameworks (like Django Rest Framework, for example) I'd really prefer this to be handled by the framework itself... My question then is, is there any built-in way to achieve this behaviour that I may be missing?
This is the BookService class:
#Stateless
#Path("/books")
public class BookService {
#Inject
private BookRepo bookRepo;
#Context
UriInfo uriInfo;
#Consumes(MediaType.APPLICATION_JSON)
#Path("/")
#POST
#Produces(MediaType.APPLICATION_JSON)
public Response create(#Valid Book book) {
bookRepo.create(book);
return Response.created(getBookUri(book)).build();
}
private URI getBookUri(Book book) {
return uriInfo.getAbsolutePathBuilder()
.path(book.getId().toString()).build();
}
}
This is the Book class:
#Entity
#Table(name = "books")
public class Book {
#Column(nullable = false)
#NotNull
#Temporal(TemporalType.TIMESTAMP)
private Date acquisitionDate;
#Column(nullable = false, updatable = false)
#GeneratedValue(strategy = GenerationType.IDENTITY)
#Id
private Integer id;
#Column(nullable = false)
#NotNull
#Size(max = 255, min = 1)
private String name;
#Column(nullable = false)
#Min(value = 1)
#NotNull
private Integer numberOfPages;
(getters/setters/...)
}
This is the BookRepo class:
#Stateless
public class BookRepo {
#PersistenceContext(unitName = "book-repo")
protected EntityManager em;
public void create(Book book) {
em.persist(book);
}
}

I don't know if this is really the answer you're looking for, but I was just playing around with the idea and implemented something.
The JAX-RS 2 spec defines a model for bean validation, so I thought maybe you could tap into that. All bad validations will get mapped to a 400. You stated "I'd prefer to prevent this exception from bubbling all the way up and present my users with, for instance, a 400 BAD REQUEST", but with bad validation you will get that anyway. So however you plan to handle validation exceptions (if at all), you can do the same here.
Basically I just created a constraint annotation to validate for a null value in the id field. You can define the id field's name in the annotation through the idField annotation attribute, so you are not restricted to id. Also this can be used for other objects too, so you don't have to repeatedly check the value, as you suggested in your second solution.
You can play around with it. Just thought I'd throw this option out there.
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import static java.lang.annotation.RetentionPolicy.RUNTIME;
import java.lang.annotation.Target;
import java.lang.reflect.Field;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.validation.Constraint;
import javax.validation.ConstraintValidator;
import javax.validation.ConstraintValidatorContext;
import javax.validation.Payload;
#Constraint(validatedBy = NoId.NoIdValidator.class)
#Target({ElementType.PARAMETER})
#Retention(RUNTIME)
public #interface NoId {
String message() default "Cannot have value for id attribute";
Class<?>[] groups() default {};
Class<? extends Payload>[] payload() default {};
String idField() default "id";
public static class NoIdValidator implements ConstraintValidator<NoId, Object> {
private String idField;
#Override
public void initialize(NoId annotation) {
idField = annotation.idField();
}
#Override
public boolean isValid(Object bean, ConstraintValidatorContext cvc) {
boolean isValid = false;
try {
Field field = bean.getClass().getDeclaredField(idField);
if (field == null) {
isValid = true;
} else {
field.setAccessible(true);
Object value = field.get(bean);
if (value == null) {
isValid = true;
}
}
} catch (NoSuchFieldException
| SecurityException
| IllegalArgumentException
| IllegalAccessException ex) {
Logger.getLogger(NoId.class.getName()).log(Level.SEVERE, null, ex);
}
return isValid;
}
}
}
Usage:
#POST
#Consumes(MediaType.APPLICATION_JSON)
public Response createBook(#Valid #NoId(idField = "id") Book book) {
book.setId(1);
return Response.created(URI.create("http://blah.com/books/1"))
.entity(book).build();
}
Note the default idField is id, so if you don't specify it, it will look for the id field in the object class. You can also specify the message as you would any other constraint annotation:
#NoId(idField = "bookId", message = "bookId must not be specified")
// default "Cannot have value for id attribute"

JPA - No validator could be found for type: enum

I have an entity class which uses an enum type for one of the properties, and I am getting the following exception when I try to persist the entity:
javax.validation.UnexpectedTypeException: No validator could be found for type: model.schema.BaseYesNo
Any idea why this might be happening? My thinking is that since it is an enum, it should already be validated by the compiler, so no need for some kind of validator. (code below)
The entity property:
#Enumerated( EnumType.STRING )
#Column( name = "seeded_flag" )
private BaseYesNo seededFlag;
public BaseYesNo getSeededFlag() {
return this.seededFlag;
}
public void setSeededFlag( BaseYesNo seededFlag ) {
this.seededFlag = seededFlag;
}
And the definition of the enum type:
public enum BaseYesNo {
YES( "Y" ),
NO( "N" );
private String yesNoVal;
private static Map< String, BaseYesNo > stringToEnum = new HashMap< String, BaseYesNo >();
static {
for ( BaseYesNo byn : BaseYesNo.values() ) {
BaseYesNo.stringToEnum.put( byn.toString(), byn );
}
}
BaseYesNo( String yesNoVal ) {
this.yesNoVal = yesNoVal;
}
public static BaseYesNo fromString( String dbValue ) {
return BaseYesNo.stringToEnum.get( dbValue );
}
#Override
public String toString() {
return this.yesNoVal;
}
}

I had the same error as you. The problem with mine was that I had mistakenly placed #Size on my enum property:
public class PhoneNumber {
#Size(max=30) //ERROR: this validation annotation is what caused my error
#Nonnull
#Enumerated(EnumType.STRING)
private Type type;
#Size(max = 30)
#Nonnull
private String number;
public enum Type {
Cell, Home, Work, Other
}
}
Once I removed the erroneous #Size, my error went away.
#Enumerated didn't cause any problems for me, and I doubt #Column would. Perhaps you had another validation annotation you skimmed over like I did.
For my testing, I was using hibernate-validator-4.1.0-Final.jar

I came across the same situation, but with the message No validator could be found for type int.
searching the web I found some solutions, most of them focus on changing type int to type Integer, because type Integer accept nulls.
like in here :
Validation - Empty int field
unfortunately that didn't work for me.
but when I substituted #size with #Min and #Max everything went great.
hoping this may gives you a hand.

I had the same error as you but the message was "No validator could be found for type: java.lang.Long. I had spent a lot of time reviewing the code until I saw the previous solution and thus, I removed all #Size entries from the entity code and also the problem went away. I should actually find out which is the offending line in the entity source code but coming from another more developer friendly platform (IBM i Series) I'll wait until the error messages are improved to give us better and accurate reasons.