@Validator, @Validate [SPR-4774]

[spring-projects-issues]

David Pedowitz opened SPR-4774 and commented

More brainstorming from training session in LA, 5/1/08 with Chris Beams, Tchavdar Ivanov (FIM) and myself.

@Validator could be a class level annotation eligible for component scans, the methods of which could be annotated with @Validate (or similar) which would enable method/request param specific validation within the request handling workflow

• Like the @HandlerInterceptor design (@HandlerInterceptor [SPR-4770] #9447) @Validator could take a list of @Controller classes for a more fine grained approach or @Controller could take a list of @Validator which would match the current register model (I think I like the later)

@Validate would define a method used to validate an @RequestParam, it'd might be neat if it handled superset of @RequestParam and @RequestMapping arguments for a very fine grained approach, i.e. @Validate("reward", method=RequestMethod.POST).

• Another option would be to register the Validator with the @RequestParam

Hope you dig the ideas

---

Issue Links:

• Support for declarative validation (Hibernate Validator, anticipating JSR 303) [SPR-69] #4803 Support for declarative validation (Hibernate Validator, anticipating JSR 303)
• Improve support for registering Validator implementations in Spring MVC [SPR-9436] #14072 Improve support for registering Validator implementations in Spring MVC ("is superseded by")

9 votes, 10 watchers

[spring-projects-issues]

Keith Donald commented

The most basic feature we can provide is the ability to detect that a form object like an AccountForm should be validated. A simple way to detect would be the AccountForm has a validate method on it, or the AccountForm has constraints specified as annotations e.g. @Required or @Length. Alternatively, a validation system could contain some mapping between an AccountForm and a set of declarative validation constraints.

[spring-projects-issues]

Krzysztof Koziol commented

I think I would be very useful to define such annotations since the annotated controllers approach lacks of Validation Processing Flow.

[spring-projects-issues]

Hamster commented

Hi,

I've been reviewing validation options and I found springmodules annotation-based validation.
https://springmodules.dev.java.net/docs/reference/0.9/html/validation.html
http://wheelersoftware.com/articles/spring-bean-validation-framework.html

Are you going to reuse those concepts and add to spring validation processing flow?

I've been watching spring 3.0 presentation and there was something about declarative validation - in javadocs for 3.x I did not found anything for that.
http://www.slideshare.net/mraible/whats-coming-in-spring-30?type=powerpoint (slide 23)

Cheers,

[spring-projects-issues]

Scott Frederick commented

With the advancement of annotation-based configuration in Spring 3.0 and 3.1, it seems like one big facet of validation has been left behind. JSR-303 java bean validation support in Spring is great, but there are still times when it is better to write a custom validation class instead of using annotations on the model (even with custom annotations). I think this Jira issue has the answer to the last missing piece of the validation puzzle.

Since Spring 3.0, most of the questions about how this could be implemented have been answered. All that is needed is the @Validator stereotype annotation and the code to detect and invoke any detected validators. Such a validator would look something like this (example from the Spring MVC Petclinic sample app):

 
import org.springframework.stereotype.Validator;
import org.springframework.validation.annotation.Validate;

@Validator(validates=Pet.class)
public class PetValidator {
    @Validate
    public void checkDuplicates(Pet pet, Errors errors) {
        if (pet.isNew() && ownerHasExistingPetWithName(pet.getOwner(), pet.getName())) {
            errors.rejectValue("name", "duplicate", "already exists");
        }
    }

    private boolean ownerHasExistingPetWithName(Owner owner, String name) {
        return owner.getPet(name, true) != null;
    }
}

As an alternative, the type to be validated could be on the @Validate annotation instead of the @Validator stereotype annotation. I've tried it both ways, I think I like the example above better but I'm interested in other opinions.

When @Valid is encountered on a controller handler method parameter, any @Validator-annotated class methods that match the type of the @Valid argument would be invoked.

This solves two big problems with existing class-based validation: it simplifies registration of validators (which is currently pretty painful) using component scanning, and it allows much more flexibility in how validator classes are written (multiple @Validate methods with meaningful names, @Validate method signatures take the appropriate type).

I have this working and can submit a patch to the current 3.1 trunk, barring any comment on the design of the @Validator and @Validate annotations.

[spring-projects-issues]

Chris Beams commented

Pull request at #30

[spring-projects-issues]

Chris Beams commented

See comments in linked pull request where I've asked Scott for additional details making the case for this feature in modern-day Spring, in light of JSR-303 support, etc.

[spring-projects-issues]

Scott Frederick commented

At Rossen's request, created two new issues to better capture the suggested improvements:

https://jira.springsource.org/browse/SPR-9436
https://jira.springsource.org/browse/SPR-9437

[spring-projects-issues]

Rossen Stoyanchev commented

I am marking this ticket as being superseded by #14072 and resolving it as duplicate. Everyone interested in the topic is encouraged to comment and place a watch on #14072 instead.

This issue was opened before Bean Validation was supported or even available and any current discussion should start with that in mind.