JSR Validation – Pauls Blog

Spring Boot Hateoas JSR Validation

Paul Sterl — Thu, 06 Feb 2020 16:00:00 +0000

Problem

By default, the JSR 303 Bean validation doesn’t work together with Spring Boot Data REST HATEOAS. Even worse we are confronted with 500 errors like

{
  "timestamp": "2020-01-01T20:52:41.336+0000",
  "status": 500,
  "error": "Internal Server Error",
  "message": "Could not commit JPA transaction; nested exception is javax.persistence.RollbackException: Error while committing the transaction",
  "trace": "org.springframework.transaction.TransactionSystemException: Could not commit JPA transaction; nested exception is javax.persistence.RollbackException: Error while committing the transaction
    at org.springframework.orm.jpa.JpaTransactionManager.doCommit(JpaTransactionManager.java:543)
    at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:744)
    at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:712)
    at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:631)
	at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:385)
....
Caused by: javax.validation.ConstraintViolationException: Validation failed for classes [xx.xxx.xxxx.xxx.YourEntity] during persist time for groups [javax.validation.groups.Default, ]
List of constraint violations:[
    ConstraintViolationImpl{interpolatedMessage='muss zwischen 1 und 1024 liegen',

In our Solutions

Imagin in the description that we have a bean-like this and of course a Spring Data repository:

@Entity @Data
public class ValidatedBean {
    @GeneratedValue
    @Id @Column(updatable = false)
    private Long id;
    @NotNull @Size(min = 2, max = 1024)
    private String name;
}
@RepositoryRestResource(path = "mybean")
public interface ValidatedBeanDAO extends JpaRepository {}

Link to the full source code.

Solution 1: custom validator

One way, of course, is to follow the Spring documentation and register validator classes, which intercept the save process. This is described here.

Advantages

Bean is validated before saving it
No transaction is started
Maybe cleaner

Disadvantages

Requires the registration of a validator
Still requires handling of response
Controller advice needed
Validation happens twice

Solution 1.1: Throw ConstraintViolationException

The most simple way to achieve this is by using the AbstractRepositoryEventListener and call the validator on your own.

Note: Import in this example the javax.validation.Validator.

@Service
public class HateoasValidationListenerConfig extends AbstractRepositoryEventListener {

    @Autowired private Validator validator;
    
    @Override
    public void onBeforeSave(Object entity) {
        final Set result = validator.validate(entity);
        if (!result.isEmpty()) {
            throw new ConstraintViolationException(result);
        }
    }
    
    @Override
    protected void onBeforeCreate(@Validated Object entity) {
        final Set result = validator.validate(entity);
        if (!result.isEmpty()) {
            throw new ConstraintViolationException(result);
        }
    }
}

This will produce by default the following result:

{
  "timestamp": "2020-01-01T20:56:41.070+0000",
  "status": 500,
  "error": "Internal Server Error",
  "message": "name: muss zwischen 2 und 1024 liegen",
  "trace": "javax.validation.ConstraintViolationException: name: muss zwischen 2 und 1024 liegen
      at xx.xxx.xxx.HateoasValidationListenerConfig.onBeforeCreate(HateoasValidationListenerConfig.java:29)

Not very „Springy“ as a Spring validation result and still error code 500. Usually, a Spring validation error looks like:

{
  "timestamp": "2020-01-01T20:58:07.957+0000",
  "status": 400,
  "error": "Bad Request",
  "errors": [
    {
      "codes": [
        "Size.ValidatedBean.name",
        "Size.name",
        "Size.java.lang.String",
        "Size"
      ],
      "arguments": [
        {
          "codes": [
            "validatedBean.name",
            "name"
          ],
          "arguments": null,
          "defaultMessage": "name",
          "code": "name"
        },
        1024,
        2
      ],
      "defaultMessage": "muss zwischen 2 und 1024 liegen",
      "objectName": "validatedBean",
      "field": "name",
      "rejectedValue": "",
      "bindingFailure": false,
      "code": "Size"
    }
  ],
  "message": "Validation failed for object='validatedBean'. Error count: 1",

Solution 1.2: Throw Custom Exception

The problem is, that Spring is still built around theBindingResult since 2.0, a far older concept & classes as the ConstraintViolation and so doesn’t provide a default exception mapper for the ConstraintViolationException. Let’s adjust our solution and use the SpringValidatorAdapter.

@Service
public class HateoasRepositoryValidationListenerConfig extends AbstractRepositoryEventListener {

    @Autowired private SpringValidatorAdapter validator;

    @Override
    protected void onBeforeCreate(Object entity) {
        BeanPropertyBindingResult errors = new BeanPropertyBindingResult(entity, 
                Introspector.decapitalize(entity.getClass().getSimpleName()));
        validator.validate(entity, errors);
        // throw a custom exception containing the spring validation result
        // which we will use later in our controller exception mapper
        if (errors.hasErrors()) {
            throw new RepositoryListenerValidationException(errors);
        }
    }
    
    @AllArgsConstructor
    public static class RepositoryListenerValidationException extends RuntimeException {
        @Getter
        private final BeanPropertyBindingResult result;
    }
}

Having this in place we need an exception mapper (@ControllerAdvice) to extract from our BeanPropertyBindingResult the ObjectError.

As so we have to add to our result first the attributes defined in the DefaultErrorAttributes furthermore by default Spring uses the BindingResult and so the FieldError in the errors attribute to return the validation result.

@ControllerAdvice
public class HateoasJsrErrorExceptionMapper {
  
    @ExceptionHandler(RepositoryListenerValidationException.class)
    public ResponseEntity handleConstraintViolation(RepositoryListenerValidationException e, ServletWebRequest request) {
        return ResponseEntity.badRequest().body(ValidationError.builder()
                .message(e.getResult().getAllErrors().get(0).getDefaultMessage())
                .path(request.getRequest().getRequestURI())
                .errors(e.getResult().getAllErrors())
                .build());
    }
    
    // Simple model class which represents our DefaultErrorAttributes.
    // The alternative would be to use DefaultErrorAttributes and set the
    // error code etc. in the request
    @Builder @Getter
    @JsonPropertyOrder({"timestamp", "status", "error", "errors", "message", "path"})
    @JsonAutoDetect(isGetterVisibility = Visibility.PUBLIC_ONLY, fieldVisibility = Visibility.NONE)
    static class ValidationError {
        final Instant timestamp = Instant.now();
        final String message;
        final String path;
        final List errors;
        public int getStatus() {
            return HttpStatus.BAD_REQUEST.value();
        }
        public String getError() {
            return HttpStatus.BAD_REQUEST.getReasonPhrase();
        }
    }
}

This will produce the expected result, which is very same as the default Spring validator will produce too.

Solution 2: extract cause exception

Alternatively, we can also extract the root cause of the TransactionSystemException, as the validation has already taken place by hibernate and a ConstraintViolationException is already attached as root cause.

Advantages

Reuses the validation result from hibernate, validation is executed once
We may handle other exceptions
Maybe anyway needed, if we want to catch other DB validation errors like unique constraints

Disadvantages

Maybe somehow hacky?
DB Transaction is started, not really fail fast

Implementation

@ControllerAdvice
public class HateoasJsrErrorExceptionMapper {
    @Autowired
    private MessageSource messageSource;
    
    @ExceptionHandler(TransactionSystemException.class)
    public ResponseEntity handleConstraintViolation(TransactionSystemException e, WebRequest request) {
        ResponseEntity result;
        
        if (e.getRootCause() instanceof ConstraintViolationException) {
            ConstraintViolationException cve = (ConstraintViolationException)e.getRootCause();
			// using model class from Spring
            ConstraintViolationExceptionMessage msg = new ConstraintViolationExceptionMessage(
                    cve, messageSource, request.getLocale());
            
            result = ResponseEntity.badRequest().body(msg);
        } else {
            result = null; // not handled here
        }
        return result;
    }
}

In the most simple way, we could, of course, use the Spring ConstraintViolationExceptionMessage, the problem with that is, that the default handler in Spring returns a list of ObjectError, which are just different in structure again.

{
  "messages": [
    {
      "message": "muss zwischen 2 und 1024 liegen",
      "invalidValue": "",
      "entity": "xx.xx.xxx.ValidatedBean",
      "property": "name"
    }
  ],
  "cause": "Validation failed for classes [xx.xx.xxx.ValidatedBean, messageTemplate='{javax.validation.constraints.Size.message}'}\n]"
}

Solution 2.1: Custom ObjectError

We have basically the same problem as in solution 1, but somehow a bit more tricky. As our source is already a list of ConstraintViolations. Well straight forward we could add a class which emulates the same structure and map jus the ConstraintViolation:

// Simpler class representing the fields of the Spring ObjectError
@Getter @ToString
static class SimpleObjectError {
    String defaultMessage;
    String objectName;
    String field;
    Object rejectedValue;
    String code;
    
    public static SimpleObjectError from(ConstraintViolation violation, MessageSource msgSrc, Locale locale) {
        SimpleObjectError result = new SimpleObjectError();
        result.defaultMessage = msgSrc.getMessage(violation.getMessageTemplate(),
                new Object[] { violation.getLeafBean().getClass().getSimpleName(), violation.getPropertyPath().toString(),
                        violation.getInvalidValue() }, violation.getMessage(), locale);
        result.objectName = Introspector.decapitalize(violation.getRootBean().getClass().getSimpleName());
        result.field = String.valueOf(violation.getPropertyPath());
        result.rejectedValue = violation.getInvalidValue();
        result.code = violation.getMessageTemplate();
        return result;
    }
}

But even using this class would produce a result like this:

{
  "timestamp": "2020-01-01T21:08:21.826429700Z",
  "status": 400,
  "error": "Bad Request",
  "errors": [
    {
      "defaultMessage": "muss zwischen 2 und 1024 liegen",
      "objectName": "validatedBean",
      "field": "name",
      "rejectedValue": "",
      "code": "{javax.validation.constraints.Size.message}"
    }
  ],
  "message": "Validation failed for classes [org.sterl.cloudadmin.impl.identity.model.IdentityBE] during persist time for groups [javax.validation.groups.Default, ]\nList of constraint violations:[\n\tConstraintViolationImpl{interpolatedMessage='muss zwischen 2 und 1024 liegen', propertyPath=name, rootBeanClass=class org.sterl.cloudadmin.impl.identity.model.IdentityBE, messageTemplate='{javax.validation.constraints.Size.message}'}\n]",
  "path": "/api/identity"
}

Solution 2.2: Bridge and reuse of SpringValidatorAdapter

A different approach could be to build a small bridge class which would allow us to access the protected method processConstraintViolations in the SpringValidatorAdapter, even if it is maybe a bit dirty:

// simple bridge to get access to the processConstraintViolations method
static class SpringValidatorBridge extends SpringValidatorAdapter {
    public SpringValidatorBridge(Validator validator) {
        super(validator);
    }
    public BeanPropertyBindingResult processConstraintViolations(ConstraintViolationException cve) {
        // get the bean which was validated
        final Object bean = cve.getConstraintViolations().iterator().next().getRootBean();

        final BeanPropertyBindingResult errors = new BeanPropertyBindingResult(bean, 
                Introspector.decapitalize(bean.getClass().getSimpleName()));
        // execute the spring code to map ConstraintViolations to ObjectError
        super.processConstraintViolations(map(cve.getConstraintViolations()), 
                errors);
        return errors;
    }
}
// needed as we have to map between  and 
static Set map(Set> input) {
    return input.stream().map(v -> (ConstraintViolation)v).collect(Collectors.toSet());
}

Having this bridge we can just call it to convert the ConstraintViolationException to a proper Spring BeanPropertyBindingResult.

@ControllerAdvice
public class HateoasJsrErrorExceptionMapper {
    private SpringValidatorBridge validatorBridge;
    
    @Autowired
    public HateoasJsrErrorExceptionMapper(Validator validator) {
        validatorBridge = new SpringValidatorBridge(validator);
    }
    
    @ExceptionHandler(TransactionSystemException.class)
    public ResponseEntity handleConstraintViolation(TransactionSystemException e, ServletWebRequest request) {
        ResponseEntity result;
        if (e.getRootCause() instanceof ConstraintViolationException) {
            ConstraintViolationException cve = (ConstraintViolationException)e.getRootCause();
            
            BeanPropertyBindingResult errors = validatorBridge.processConstraintViolations(cve);
            result = ResponseEntity.badRequest().body(ValidationError.builder()
                    .message(cve.getMessage())
                    .path(request.getRequest().getRequestURI())
                    .errors(errors.getAllErrors())
                    .build());
        } else {
            result = null; // not handled here
        }
        return result;
    }

In the end, we can again pass the list of ObjectErrors to our created ValidationError class, like in solution 1 and we receive the expected result from it.

Which solution to use?

Well to decide this depends on the personal taste. I personally like the 1.2 solution the most because it has the advantage to fail fast and is maybe somehow cleaner. But in then I end up doing the validation twice of course. Once on my event listener and once by hibernate.

Overall it depends on the personal taste and if it is anyway needed to catch and handle DB errors too. As so we need maybe both solutions.

Spring Data MongoDB and JSR Validation using Lazy DBRef

Paul Sterl — Tue, 08 Mar 2016 12:34:40 +0000

The Problem

Recently using MongoDB and Spring Data I encountered an interesting issue. Saving an Entity which was loaded by @DBRef(lazy = true) wasn’t possible together with the activated ValidatingMongoEventListener. Each time the following error occurred:

javax.validation.ConstraintViolationException
	at org.springframework.data.mongodb.core.mapping.event.ValidatingMongoEventListener.onBeforeSave(ValidatingMongoEventListener.java:65)
	at org.springframework.data.mongodb.core.mapping.event.AbstractMongoEventListener.onBeforeSave(AbstractMongoEventListener.java:144)
	at org.springframework.data.mongodb.core.mapping.event.AbstractMongoEventListener.onApplicationEvent(AbstractMongoEventListener.java:90)
	at org.springframework.data.mongodb.core.mapping.event.AbstractMongoEventListener.onApplicationEvent(AbstractMongoEventListener.java:33)
	at org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:163)
	at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:136)
	at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:381)
	at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:335)
	at org.springframework.data.mongodb.core.MongoTemplate.maybeEmitEvent(MongoTemplate.java:1633)
	at org.springframework.data.mongodb.core.MongoTemplate.doSave(MongoTemplate.java:986)
	at org.springframework.data.mongodb.core.MongoTemplate.save(MongoTemplate.java:933)
	at org.springframework.data.mongodb.repository.support.SimpleMongoRepository.save(SimpleMongoRepository.java:78)

The Issue

Well, looking into the details it is quite clear — as a dynamic proxy is passed to the validation which fields are all null. As so any validation on the Entity will always fail. The code of the validator itself doesn’t really show the obvious miss take — only if you compare it with the save method the problem gets pretty clear.

ValidatingMongoEventListener

public void onBeforeSave(Object source, DBObject dbo) {

  LOG.debug("Validating object: {}", source);
  Set violations = validator.validate(source);

  if (!violations.isEmpty()) {

    LOG.info("During object: {} validation violations found: {}", source, violations);
    throw new ConstraintViolationException(violations);
  }
}

MappingMongoConverter

Compared to the Spring Mongo Mapper code, which is responsible to store the entity it’s clear what we have to do.

public void write(final Object obj, final DBObject dbo) {

  if (null == obj) {
    return;
  }

  Class entityType = obj.getClass();
  boolean handledByCustomConverter = conversions.getCustomWriteTarget(entityType, DBObject.class) != null;
  TypeInformation type = ClassTypeInformation.from(entityType);

  if (!handledByCustomConverter && !(dbo instanceof BasicDBList)) {
    typeMapper.writeType(type, dbo);
  }

  Object target = obj instanceof LazyLoadingProxy ? ((LazyLoadingProxy) obj).getTarget() : obj;

  writeInternal(target, dbo, type);
}

Solution

As so we have to replace the Spring provided Validation Listener with an own — till Spring fixes the issue:

public class FixedMongoValidation  extends AbstractMongoEventListener {
  private final Validator validator;
  public FixedMongoValidation(Validator validator) {
    Assert.notNull(validator);
    this.validator = validator;
  }
  @Override
  @SuppressWarnings({ "rawtypes", "unchecked" })
  public void onBeforeSave(Object obj, DBObject dbo) {

    Object target = obj instanceof LazyLoadingProxy ? ((LazyLoadingProxy) obj).getTarget() : obj;
    Set violations = validator.validate(target);

    if (!violations.isEmpty()) {

      LOG.info("During object: {} validation violations found: {}", target, violations);
      throw new ConstraintViolationException(violations);
    }
  }
}

And of course don’t forget to change the configuration to ensure your fixed class is used.

// JSR Validation for MongoDB Entities
@Bean
public ValidatingMongoEventListener validatingMongoEventListener() {
  return new ValidatingMongoEventListener(validator());
}
@Bean
public LocalValidatorFactoryBean validator() {
  return new LocalValidatorFactoryBean();
}

Links

Pull Request in Spring Data Project

JSR 303 Validation for Dates

Paul Sterl — Thu, 11 Jun 2015 20:17:55 +0000

A common case is to validate date inputs in Java e.g. to avoid the nice and friendly typos like 06/01/1500.

Nevertheless by default where is not to much support to handle this very common case. So let’s fix this together:

Annotation first

The first we need is a JSR annotation which we use to annotate the code. We provide from the start proper default values, to avoid none sense data.

import java.lang.annotation.Documented;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
import javax.validation.Constraint;
import javax.validation.Payload;

@Documented
// Note: We use here already a validator which we will add in a sec too
@Constraint(validatedBy = InDateRangeValidator.class)
@Target({ElementType.METHOD, ElementType.FIELD, ElementType.ANNOTATION_TYPE})
@Retention(RetentionPolicy.RUNTIME)
public @interface InDateRange {
    // used to get later in the resource bundle the i18n text
    String message() default "{validation.date.InDateRange.message}";
    Class[] groups() default {};
    Class[] payload() default {};
    // min value, we for now just a string
    String min() default "1900-01-01";
    // max date value we support
    String max() default "2999-12-31";
}

Validator next

As we have the annotation now, we still need to add some code behind for the JSR bean validation to make it really do something. I assume that both classes are in the same package.

import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Date;
import javax.validation.ConstraintValidator;
import javax.validation.ConstraintValidatorContext;

public class InDateRangeValidator implements ConstraintValidator {
    
    private final SimpleDateFormat dateParser = new SimpleDateFormat("yyyy-MM-dd");
    
    private InDateRange constraintAnnotation;
    
    @Override
    public void initialize(InDateRange constraintAnnotation) {
        this.constraintAnnotation = constraintAnnotation;
    }
    
    @Override
    public boolean isValid(java.util.Date value, ConstraintValidatorContext context) {
        try {
            final Date min = dateParser.parse(constraintAnnotation.min());
            final Date max = dateParser.parse(constraintAnnotation.max());
            return value == null ||
                    (value.after(min) && value.before(max));
        } catch (ParseException ex) {
            throw new RuntimeException(ex);
        }
    }
}

The validator is not very smart now, but it will do the job for. Let’s use it first, will we?

Note: This tutorial is a bit old, use nowadays the DateTimeFormatter from the Java time.

Apply our date validation

class SomeBean {
    @InDateRange
    private Date date;
}

Well not to surprising but the interesting part is of course always the test case we should add to verify all is good and working as we like it.

import java.util.Date;
import java.util.Set;
import org.junit.Test;
import static org.junit.Assert.*;
import org.junit.BeforeClass;
import javax.validation.ConstraintViolation;
import javax.validation.Validation;
import javax.validation.Validator;
import javax.validation.ValidatorFactory;
import org.joda.time.LocalDate;

public class TestInDateRange {

    private static Validator validator;
    
    @BeforeClass
    public static void setUp() {
        ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
        validator = factory.getValidator();
    }
    
    @Test
    public void testDateRange() {
        SomeBean test = new SomeBean();
        test.date = new LocalDate(10001, 01, 01).toDate();
        
        Set> validate = validator.validate(test);
        System.out.println(validate);
        assertEquals(1, validate.size());
        assertEquals("date", validate.iterator().next().getPropertyPath().toString());
    }
}

i18n File

Assuming you use a default maven project we should add in /src/main/resources the file ValidationMessages.properties if it not already exists:

validation.date.InDateRange.message=date must be between {min} and {max}.

Note: You can use placeholders in the messages string. Here we use min and max, which automatically add the values from our annotation into the user message.

Going further

Well as you noticed right now we parse the min and max date each time. We could of course just do this once as it is quite static
We use currently java.util.Date well again something we could change
Last but not least we should try to avoid Date in the API / Model objects and try to just use simply UTC Longs