Skip to main content

Spring MVC, Spring Bean Validation Framework and validating confirm password / confirm email fields.

How to write validation like confirm password, confirm email and etc in Spring MVC.
NOTE: To make bean validation to work its nice to read this tutorial: <a href="http://wheelersoftware.com/articles/spring-bean-validation-framework.html"></a>
Today I was busy making some validations and implementations on very common scenario:
change email and password.
So we have a new password AND a new email also for both of them we have a confirm email/password field. And we want to validate everything nicely and to show to the user the real validation message if there is some error.
So ... I've to use a form which already uses some annotations like @NoBlank and etc I think everyone of you is using annotations framework if you don't use it SHAME ON YOU !:)

Anyway so I've added some fields to existing form bean:
private String newPassword;
private String confirmNewPassword;
private String newEmail;
private String confirmNewEmail;

Basiclly in my case this is very big form and none of this fields is mendatory so the user can leave all of them blank. My first idea was to add at least Length for the password and Email annotations for the email so I do:
@Length(min=6,max=20)
private String newPassword;
private String confirmNewPassword;
@Email
private String newEmail;
private String confirmNewEmail;

Ok but the confirm fields should have the same rules ? Maybe...
The problem that I saw is that length and email by default means NotBlank.
To make email validator to work or length validator they first check is the field blank. In my case I want the blank to be OK.. so I asked god google what to do.
The answer applyIf.
So at the end I get :
@Length(min = 6, max = 20, applyIf = "newPassword is not blank") //cool right ?
private String newPassword;
private String confirmNewPassword;
@Email(applyIf = "newEmail is not blank") //cool right ?
private String newEmail;
private String confirmNewEmail;

Cool right ? yep it is cool. but let me add the validation for confirmNewPassword and confirmNewEmail.
@Length(min = 6, max = 20, applyIf = "newPassword is not blank")
private String newPassword;
@NotBlank(applyIf = "newPassword is not blank")
private String confirmNewPassword;

@Email(applyIf = "newEmail is not blank")
private String newEmail;
@NotBlank(applyIf = "newEmail is not blank")
@Email(applyIf = "newEmail is not blank")
private String confirmNewEmail;

Nice.. so I have validation on new* fields only if they are not blank. Also I have a validation on the confirm fields only if again new* fields are not blank.
Cool... what left ? ahh the most hard part to check is the confirmpassword the same as the newPassword and is the confirmEmail same as the newEmail.
the first idea ofcourse is to write a custom validator.
So I write this :
class NewPassAndEmailValidator implements Validator {
    @Override
    public boolean supports(Class<?> clazz) {
        return PersonalDetailsFormBean.class.equals(clazz);
    }

    @Override
    public void validate(Object obj, Errors errors) {
        PersonalDetailsFormBean personalDetailsFormBean = (PersonalDetailsFormBean) obj;
        if (personalDetailsFormBean.getNewPassword() != null
                && !personalDetailsFormBean.getNewPassword().equals("")) {
            if (!personalDetailsFormBean.getNewPassword().equals(personalDetailsFormBean.getConfirmNewPassword())) {
                errors.rejectValue("confirmNewPassword", "PersonalDetailsFormBean.confirmNewPassword[customvalidator]");
            }
        }
        if (personalDetailsFormBean.getNewEmail() != null && !personalDetailsFormBean.getNewEmail().equals("")) {
            if (!personalDetailsFormBean.getNewEmail().equals(personalDetailsFormBean.getConfirmNewEmail())) {
                errors.rejectValue("confirmNewEmail", "PersonalDetailsFormBean.confirmNewEmail[customvalidator]");
            }
        }
    }

}
and then in the controller submit method.
validator.validate(personalDetailsFormBean, result); //this invokes the annotation based validator.
NewPassAndEmailValidator newPassAndEmailValidator = new NewPassAndEmailValidato();
newPassAndEmailValidator.validate(personalDetailsFormBean, result);

if (result.hasErrors()) {
... return...
}

This .... WORKS FINE. BUT... ah its not cool :( ... I mean even in struts 1 in 2001 we ware having a validation based on expression. AND we have even better way here... Awesome :D
So I've removed this validator... and write only "this":
@Expression(value = "confirmNewPassword = newPassword", applyIf = "newPassword is not blank")
So the final example looks like this:
@Length(min = 6, max = 20, applyIf = "newPassword is not blank")
private String newPassword;
@NotBlank(applyIf = "newPassword is not blank")
@Expression(value = "confirmNewPassword = newPassword", applyIf = "newPassword is not blank")
private String confirmNewPassword;

@Email(applyIf = "newEmail is not blank")
private String newEmail;
@NotBlank(applyIf = "newEmail is not blank")
@Email(applyIf = "newEmail is not blank")
@Expression(value = "confirmNewEmail = newEmail", applyIf = "newEmail is not blank")
private String confirmNewEmail;

:) ok this looks cool :D maybe not so cool than 20+ if statements to checks for null for some of you to but I like this way :))

Comments

Unknown said…
This is exactly what I was looking for. Checking equality of fields using annotations. Great post, thanks.
Reuben said…
Yes, very cool. Thanks for sharing.
Thanks a lot, JOke. The example of @Expression is very useful. I found it nowhere but here.

Kind regards
Vuong
Unknown said…
Awesome Buddy..
thnx a million......

Popular posts from this blog

Convert PFX certificate to JKS, P12, CRT

I recently had to use a PFX certificate for client authentication (maybe another post will be coming) and for that reason I had to convert it to a Java keystore (JKS).  We will create BOTH a truststore and a keystore, because based on your needs you might need one or the other.  The difference between truststore and keystore if you are not aware is(quote from the JSSE ref guide : TrustManager: Determines whether the remote authentication credentials (and thus the connection) should be trusted. KeyManager: Determines which authentication credentials to send to the remote host. Ok that's enough what you will need is openssl and Java 7+ ;) ! First let's generate a key from the pfx file, this key is later used for p12 keystore. openssl pkcs12 -in example.pfx -nocerts -out  example .key   Enter Import Password: MAC verified OK Enter PEM pass phrase: Verifying - Enter PEM pass phrase: As shown here you will be asked for the password of the pfx file, l

Hibernate Generic DAO.

When you use Hibernate and DAO pattern it is a good idea to use a Generic Base Dao. The fallowing code snippet contains GenericDAO that is a base class for all my DAO classes. This GenericDAO uses HibernateDaoSupport from Spring for its implementation if you want you can use JpaDaoSupport or JdbcDaoSupport in your projects. My Generic DAO interface looks like this : package org.joke.myproject.dao.base; import java.io.Serializable; import java.util.List; /** * @author Naiden Gochev * @param <E> * @param <PK> */ public interface GenericDao<E,PK  extends Serializable> {     PK save(E newInstance);     void update(E transientObject);     void saveOrUpdate(E transientObject);     void delete(E persistentObject);     E findById(PK id);     List<E> findAll();     List<E> findAllByProperty(String propertyName,Object value); } All method names are very common so I don't

Patching a Maven library with your custom class.

Sometimes you use a library that has a bug. Or maybe it doesn’t has a bug but you want to change something. Of course if it is an open source you can get the sources… build them … with your change and so on. However this first takes a lot of time and second you need the sources. What you usually want .. is to just replace one class.. or few classes with something custom… maybe add a line .. or remove a line and so on. Yesterday… I had an issue with jboss-logging. The version I was using was 3.2.0Beta1 and it turns out that using this version and log4j2 2.0 final basically meant that no log is send to log4j2. The reason was a null pointer exception that was catched in jboss logging class called Log4j2Logger. The bug I submitted is here https://issues.jboss.org/browse/JBLOGGING-107 and it was fixed at the same day. However I will use it as an example since I didn’t knew when this will be fixed.. and I didn’t want to wait till it is fixed. So I was thinking what I want.. to take the j