@Valid. That wonderful little annotation. In my Spring controller I do something like this.
@RequestMapping( value="/editAccount", method=RequestMethod.POST )
public String postEditAccount( Model model, HttpServletRequest request,
@Valid AccountInfo info, BindingResult infoResult )
and everything is great. I know that all of the JSR-303 annotations I’ve put on my AccountInfo bean have been validated and the data is all correct and good. Let’s say that my AccountInfo bean looks something like this.
public class AccountInfo
{
@NotNull
private String username;
@NotNull
private String newUsername;
@NotNull
private String confirmNewUsername;
@NotNull
private String password;
@NotNull
private String newPassword;
@NotNull
private String confirmNewPassword;
@NotNull
private String firstName;
@NotNull
private String lastName;
@NotNull
private String phone;
private String fax;
// constructors, getters, setters, etc. down here
}
Suddenly, everything isn’t so hunky dory anymore. Fortunately for us, JSR-303 has a great mechanism for only validating some portion of the object. It’s known as validation groups. There’s plenty of information out there on them, so I’ll give you the extreme Reader’s Digest version. Basically, you specify a list of marker interfaces in your validation annotations, and then when you call the validator, you can also pass in a list of the marker interfaces that you would like to validate against. Ok, that sentence doesn’t make much sense unless you already know about groups. So, here’s a new version of AccountInfo that demonstrates.
public class AccountInfo
{
@NotNull( groups={ChangeUsername.class} )
private String username;
@NotNull( groups={ChangeUsername.class} )
private String newUsername;
@NotNull( groups={ChangeUsername.class} )
private String confirmNewUsername;
@NotNull( groups={ChangePassword.class} )
private String password;
@NotNull( groups={ChangePassword.class} )
private String newPassword;
@NotNull( groups={ChangePassword.class} )
private String confirmNewPassword;
@NotNull
private String firstName;
@NotNull
private String lastName;
@NotNull
private String phone;
private String fax;
// constructors, getters, setters, etc. down here
public interface ChangePassword {};
public interface ChangeUsername {};
}
Now we’ve told the validator that when we run the validator without any groups, we want it to validate firstName, lastName, and phone. If you don’t specify any groups, they get the Default.class group. BUT, if we run the validator passing in the AccountInfo.ChangePassword.class, then it will only validate password, newPassword, and confirmNewPassword. If we want to do both, then we can pass in AccountInfo.ChangePassword.class AND Default.class and it will validate both groups. That’s awesome sauce right there. Now, we can use this same backing bean in the page where the user is created which contains all the fields, we can use it in the edit account info page which only has the stuff validated by Default, we can use it in our change password page, and we can also use it in our change username page, and in each case, we only validate the portions that we are concerned about for those pages. One bean for all four pages.
With that worked out, we should be able to just add the groups to our @Valid annotation, right? Nope. Wait, what? All that work to put in validation groups and we can’t even use them with the JSR-303 sanctioned validation annotation? Yep, that’s right. There’s an improvement in Spring’s Jira to add a new @Valid annotation that will allow you to specify groups, but until that happens, you’ll have to run the validator yourself.
I think it sound worse than it is. As you can see in the controller method I put at the start of this post, that after each @Valid annotated object, you need to have the BindingResult in order to see the errors. Then, in your controller method you have to check the BindingResult in order to see if there are errors, if there are, do something, if not, do something else. So, how is that any different than having to just run the check yourself? Here’s what I did.
/**
* Test validity of an object against some number of validation groups, or
* Default if no groups are specified.
*
* @param result Errors object for holding validation errors for use in
* Spring form taglib. Any violations encountered will be added
* to this errors object.
* @param o Object to be validated
* @param classes Validation groups to be used in validation
* @return true if the object is valid, false otherwise.
*/
private boolean isValid( Errors result, Object o, Class<?>... classes )
{
if ( classes == null || classes.length == 0 || classes[0] == null )
{
classes = new Class<?>[] { Default.class };
}
Validator validator = Validation.buildDefaultValidatorFactory().getValidator();
Set<ConstraintViolation<Object>> violations = validator.validate( o, classes );
for ( ConstraintViolation<Object> v : violations )
{
Path path = v.getPropertyPath();
String propertyName = "";
if ( path != null )
{
for ( Node n : path )
{
propertyName += n.getName() + ".";
}
propertyName = propertyName.substring( 0, propertyName.length()-1 );
}
String constraintName = v.getConstraintDescriptor().getAnnotation().annotationType().getSimpleName();
if ( propertyName == null || "".equals( propertyName ))
{
result.reject( constraintName, v.getMessage());
}
else
{
result.rejectValue( propertyName, constraintName, v.getMessage() );
}
}
return violations.size() == 0;
}
Alright, it’s a pretty simple method, but we’ll walk through it.
Validator validator = Validation.buildDefaultValidatorFactory().getValidator();
Set<ConstraintViolation<Object>> violations = validator.validate( o, classes );
Here we get the validator instance and get the set of violations back. This is based on the validation groups that were passed in, or Default if there were none passed. I believe I read somewhere that you can actually get the Validator injected by Spring, but I haven’t played with it yet to find out. If you do and it works, let me know!
Next is the part where we take the JSR-303 validations and map them to Spring form errors.
Path path = v.getPropertyPath();
String propertyName = "";
if ( path != null )
{
for ( Node n : path )
{
propertyName += n.getName() + ".";
}
propertyName = propertyName.substring( 0, propertyName.length()-1 );
}
We get the property name of the violation, which will hopefully map to the “path” in the spring input tag you are using. I haven’t tested this on anything with any depth (for instance, if your bean contains an object that also has validation annotations on it) so I’m not sure how it’ll work there. Once again, if you find out, leave a comment. Anyway, now that we have the property name, we can use that later on to tell Spring which field failed validation so the correct errors field can be shown.
String constraintName = v.getConstraintDescriptor().getAnnotation().annotationType().getSimpleName();
Now we get the name of the constraint that failed. In all cases above, it would be NotNull. If you annotation is something like @Size( min=85 ) then the constraint would be Size. We use this so we can get error messages mapped the same way spring binding violations do, so if you are using custom messages in your messageSource for your fields or constraint messages, then this should work just the same.
if ( propertyName == null || "".equals( propertyName ))
{
result.reject( constraintName, v.getMessage());
}
else
{
result.rejectValue( propertyName, constraintName, v.getMessage() );
}
Finally, before returning the true or false, we have to add the violations to the Errors object. If we have a propertyName, then that means it’s a field error. If we don’t, it’s a global object error, which ought to happen if you use a class level validation annotation instead of a field level validation annotation. Yep, I’m going to say it one more time. I haven’t tested that yet, but it won’t be long before I do since I’ve got to get a class level validator to ensure the newPassword and confirmNewPassword fields contain the same value.
So, that’s a lot of explaining for a single method, but hopefully it shows that adding this validation really isn’t that much more difficult than checking the BindingResult that Spring gives back to you after the default @Valid processing. In places where I don’t have to use validation groups, I’m obviously still going to use the @Valid annotation as is, and if Spring gives me a new annotation I can use to run validation groups, I’ll jump to that and rip this out right away. BUT, until then, this will have to do.
Finally, here’s how I call that method in my controller.
@RequestMapping( value="/editAccount", method=RequestMethod.POST )
public String postEditAccount( Model model, HttpServletRequest request,
AccountInfo info, BindingResult infoResult )
{
if ( !isValid( infoResult, info, AccountInfo.ChangePassword.class, AccountInfo.ChangeUsername.class ))
{
return "editAccount";
}
// otherwise we process the form and do stuff.
}
Obviously, you would want to move the isValid method out of this controller and into something that can be shared between Controllers.
