![[ Puerto Cero Uno ]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhiXs7hWiiK0_ETMqSqjEYdPtKVGAtAw_S16cM3u-3t1kwYIw-FM1aSQeOkrlr9lmqom-9Kw9kz0ZoPNXfpYGC_CIbLwn20L7Ps3leRsUpjPp63xioaYTeMLJsI-2JnRc8mWwH76Jbhn-jx/s752/puertocerounobanner.jpg)
Trabajaremos con las siguientes dependencias Maven:
javax.validation validation-api 1.1.0.Final compile org.hibernate hibernate-validator 5.1.0.Final runtime org.jboss.logging jboss-logging 3.2.0.GA runtime
En grandes aplicaciones, nos encontramos con el caso de tener que almacenar complejos objetos de negocio que se han de persistir de alguna manera.
La mayoria de estos objetos han de cumplir una serie de reglas de negocio. Por ejemplo, pensemos en un objeto “Usuario”, muy posible que los valores de sus atributos “username”, “password” deban ser “No nulos”, cumplir con una determinada longitud minima e incluso un contener un conjunto de caracteres especificos. Por otro lado, un objeto “CarritoDeCompra”, podria estar restringido a que su atributo “cantidad” sea mayor que 0 antes de ser guardar y “duracionCompra” estar dentro de un rango que permita la aplicacion.
A veces, dichas reglas de negocio pueden tornarse bastante complejas. La expresion regular que se usa para validar una dirección “e-mail”.
^[a-z0-9`!#$%^&*'{}?/+=|_~-]+(\.[a-z0-9`!#$%^&*'{}?/+=|_~-]+)*@ ([a-z0-9]([a-z0-9-]*[a-z0-9])?)+(\.[a-z0-9]([a-z0-9-]*[a-z0-9])?)*$
Esta parte de validacion de reglas de negocio, puede resultar bastante engorrosa teniendo en cuenta el numero de reglas por Objeto(s) y la cantidad de codigo que requieren. Veamos un ejemplo de objeto “Cliente”:
/*Ejemplo de validacion corriente del objeto "Customer" */
if(customer.getFirstName() == null ||
customer.getFirstName().trim().length() == 0)
throw new ValidationException("validate.customer.firstName");
if(customer.getLastName() == null || customer.getLastName().trim().length() == 0)
throw new ValidationException("validate.customer.lastName");
if(customer.getGovernmentId() == null ||
customer.getGovernmentId().trim().length() == 0)
throw new ValidationException("validate.customer.governmentId");
if(customer.getBirthDate() == null ||
customer.getBirthDate().isAfter(yearsAgo(18)))
throw new ValidationException("validate.customer.birthDate");
if(customer.getGender() == null)
threw new ValidationException("validate.customer.gender");
if(customer.getBadgeNumber() == null ||
customer.getBadgeNumber().trim().length() == 0)
throw new ValidationException("validate.customer.badgeNumber");
if(customer.getAddress() == null || customer.getAddress().trim().length() == 0)
throw new ValidationException("validate.customer.address");
if(customer.getCity() == null || customer.getCity().trim().length() == 0)
throw new ValidationException("validate.customer.city");
if(customer.getState() == null || customer.getState().trim().length() == 0)
throw new ValidationException("validate.customer.state");
if(customer.getPhoneNumber() == null ||
customer.getPhoneNumber().trim().length() == 0)
throw new ValidationException("validate.customer.phoneNumber");
if(customer.getEmail() == null || customer.getEmail().trim().length() == 0 ||
!EMAIL_REGEX.matcher(customer.getEmail()).matches())
throw new ValidationException("validate.customer.email");
if(customer.getDepartment() == null ||
lookupService.getDepartment(customer.getDepartment()) == null)
throw new ValidationException("validate.customer.department");
if(customer.getLocation() == null ||
lookupService.getLocation(customer.getLocation()) == null)
throw new ValidationException("validate.customer.location");
Como vemos, no hemos escrito aún el codigo para persistir a “customer” y vemos la cantidad de necesario para verificar unicamente si “customer” es correcto.
Afortunadamente, el API de Bean Validation nos permitira validar de manera declarativa (como veremos) los distintos beans. Esto se realiza a traves de unas anotaciones con las que se escriben las reglas de negocio para una clase dada, junto con el API para manejar los objetos de Validacion.
Basada en la JSR 303, JavaBean Validation 1.0, se añadio a la plataforma Java EE 6. Por otro lado Javabean validation 1.1, se basa en la JSR 349, es su sucesora en Java EE 7. Esta ultima añade como mejora, la validacion de los argumentos y validacion de los valores de retorno de un metodo, permite ademas el uso de “expresiones” dentro de los mensajes de error de validacion. En los ejemplos usaremos la implementacion Hibernate Validator 5.1.
Mientras que JSR 349 especifica que debe cumplir el API de validacion y los metadatos. Hibernate Validator 5.0 es la implementacion de dicha JSR 349, ademas es la mas comunmente usada. (Existe una version 5.1 con numerosas mejoras).
Hibernate Validator es el punto de partida del standard Bean Validation. Inicialmente, Hibernate Validator formaba parte del framework ORM Hibernate, aportando la validacion de entidades antes de persistirlas en la base de datos. Mas tarde, evolucionaria hacia el estandard Bean Validation.
El funcionamiento de Bean Validation se realiza mediante la anotacion de atributos, metodos y demas, de manera que establecemos una restriccion sobre el elemento anotado. Para cualquier anotacion cuya “retention policy” es runtime (la anotacion sigue existiendo despues de compilar y esta disponible como metadato en runtime) y que se anota mediante @javax.validation.Constraint representa dichas restriccion. El API provee con anotaciones predefinidas, pero es posible crear nuestras propias “javax.validation.ConstraintValidator”. Un ConstraintValidator se encarga de procesar un tipo de constraint concreto. is responsible for evaluating a particular constraint type. Las constraints que aporta el API por defecto, no se crean a partir de ConstraintValidator s ya que se manejan de manera interna por el API.
Las anotaciones de Constraint al aplicarlas a un atributo, indican al validador que debe comprobar que se cumple, cada vez que se invoca el metodo de validacion en una instancia de dicha clase. Cuando se coloca en un setter/getter de un JavaBean, se trata de una alternativa a anotar directamente el atributo. Anotar un metodo de un interfaz indica que la constraint debe aplicarse sobre el valor de retorno de dicho metodo. Anotar uno o varios parametros de un metodo de un interfaz indica que dichos parametros han de validarse antes de la ejecucion del metodo. Estas dos ultimas formas de aplicar constraints facilitan el estilo de “programacion por contrato” (PbC). El creador del interfaz, especifica un contrato que debe cumplir dicha interfaz, como unos valores que deben ser siempre “No Nulos”, o que los parametros de sus metodos deben cumplir ciertas reglas. El consumidor del interfaz, de manera que la parte de la implementacion y la parte consumidora sabran que el contrato se rompe si se viola alguna de las constraints.
Con las anotaciones Bean Validation usadas como constraints de PbC , necesitamos crear un proxy para validar las clases de contendran la implementacion. Esto nos sugiere de una forma la Inyeccion de Dependencias (DI), de los Consumidores para realizar la llamada efectiva al proxy con su implementacion. Existen varios Java EE AS que implementan la capacidad que ofrece Java EE 7 de realizar Programacion por Contrato, mediante proxies que aplican DI validada. Sin embargo, cuando usamos un contenedor de servlets como puede ser Tomcat, debemos aportar nuestra propia solucion para DI.
El Framework Spring, crea automaticamente los proxies necesarios para los beans que maneja y que usan Java Bean Validation. Las llamadas a los metodos anotados, se interceptan y validan apropiadamente, ya sea o bien los argumentos que pasa el Consumer son validos, o bien que el valor retornado por la implementacion es correcto. De esta manera, es frecuente el uso de Bean Validation en clases de tipo @Service ya que de forma conceptual, se trata de los beans que han de manejar la logica de negocio. El framework tambien valida cualquier tipo de objeto o metodo anotado con constraints que se pasan a un metodo de @Controller si dichos parametros se marcan con @javax.validation.Valid .
Aun cuando no configuremos Bean Validation dentro de Spring, podemos hacer uso de la validacion, si lo tenemos dentro de nuestras dependencias.
Una prueba seria:
ValidatorFactory factory = Validation.buildDefaultValidatorFactory(); Validator validator = factory.getValidator(); Set violations = validator.validate(employee); if(violations.size() > 0) throw new ConstraintViolationException(violations);
Aunque el codigo funcionaria, no es nuestra intencion usarlo asi. Queremos usarlo de manera mas automatizada, para conseguirlo debemos configurar 4 puntos:
1. Declarar un “validator” 2. Configurar Message localization para el “validator” 3. Declarar “method validation processor” 4. Incluir el validator en Spring MVC form validation
En cuanto a la Maven dependency de Hibernate Validator excluye la dependencia JBoss Logging API (ya que Hibernate la usa en lugar de la dependencia Commons Logging como su API para loggings), y esto se hace en runtime, por lo que JBoss Logging dependency se declara de forma independiente. El artifact hibernate-validator declara una dependencia sobre una version de jboss-logging que no soporta Log4j 2, asi que es necesario incluir la dependencia mas reciente que lo soporte. La exclusion no es absolutamente necesaria, pero se muestra como aclaracion.
Antes de la version de Spring 4.0, el soporte para Bean Validation se centraba en las implementaciones Hibernate Validator 4.2 o 4.3. Esto es debido a que dicha implementacion aporta ciertas caracteristicas necesarias para aspectos de Spring i18n. Sin embargo en Spring 4.0, cualquier implementacion de Bean Validations 1.1 funciona ya que en esta version dichas caracteristicas se han estandarizado. En caso de estar restringidos al uso de Bean Validation 1.0 nos vemos forzados a usar Hibernate Validator (4.2 o 4.3).
El soporte automatico para validar objetos en Spring es anterior a que los estandares de Bean Validation apareciesen. La interfaz org.springframework.validation.Validator indica una forma de validar objetos basada en annotation constraints. Dichas constraints y su aplicacion se uso al principio dentro del proyecto llamado Spring Modules Validation, que desaparecio al aparecer el estandar JSR 303. Actualmente esta interfaz de Spring Validator sirve como facade para el API Bean Validation. Es importante tener esto en cuenta ya que los errores de validacion que reporta Spring los realiza a traves del interfaz org.springframework.validation.Errors y no en una coleccion retornada de tipo Set<javax .validation.ConstraintViolation<?>> . . La interfaz Errors, permite acceder a uno o varios objetos org.springframework.validation.ObjectError y a uno o varios org.springframework .validation.FieldError. A fecha actual, es posible usar Spring Validator o bien javax.validation.Validator, segun prefiramos, pero existen casos en los que nos vemos forzados a utilizar Spring Validator y sus objetos Errors .
Nota Para evitar confundirnos, cada vez que nos referimos a “ Validator ”, nos estamos refiriendo a javax.validation.Validator a menos que se indique lo contrario. Sin embargo en “Spring Validator” nos referimos a org.springframework.validation.Validator
Al configurar soporte para validacion en Spring, hemos de declarar un Bean especifico (una clase que extienda de org.springframework.validation.beanvalidation.SpringValidatorAdapter que implemente tanto a “Validator” como “Spring Validator” . De forma interna, este Bean utiliza un Validator para dar soporte en operaciones de ambas interfaces (facade). Podemos usar una de estas dos opciones:
javax.validation.beanvalidation.CustomValidatorBean
javax.validation.beanvalidation.LocalValidatorFactoryBean
En la mayoria de casos, usamos “LocalValidatorFactoryBean”, ya que permite recuperar el objeto interno Validator y al mismo tiempo nos permite utilizar el mismo “MessageSource” y ficheros de mensajes que se usan para realizar el resto de la i18n en la aplicacion. De una forma sencilla, configurar el bean “LocalValidatorFactoryBean” seria instanciarlo y retornarlo de esta manera.
/*****/
@Bean methodo de la clase RootContextConfiguration class:
@Bean
public LocalValidatorFactoryBean localValidatorFactoryBean()
{
return new LocalValidatorFactoryBean();
}
El Bean “LocalValidatorFactoryBean” detectara de manera automatica la implementacion de Bean Validation dentro del classpath, si se trata de Hibernate Validator o de otra implementacion, y usara javax.validation.ValidatorFactory, como factoria por detras. No es necesario configurar el fichero de validacion “META-INF/validation.xml”. Aunque a veces, existen mas de un proveedor de Bean Validation en el classpath (un ejemplo seria al ejecutar la aplicacion dentro de un AS como GlashFish o WebSphere).
En estos casos, no sabemos a ciencia cierta, cual es el proveedor de Bean Validation que seleccionara Spring, que incluso puede variar de una vez a otra. En este caso es recomendable establecer el proveedor de forma manual.
/****/
@Bean
public LocalValidatorFactoryBean localValidatorFactoryBean()
{
LocalValidatorFactoryBean validator = new LocalValidatorFactoryBean();
validator.setProviderClass(HibernateValidator.class);
return validator;
}
La unica pega de realizar esta configuracion es que necesitamos que la dependencia Hibernate Validator se realize en tiempo de compilacion en lugar de runtime. Esto sobrecarga de mensajes en tiempo de compilacion, en los que nuestro IDE, puede resaltar nuestro codigo con sugerencias a clases que no son las que hemos de usar. Para evitar esto, es posible cargar las clases de manera dinamica, lo que tiene como contrapartida que cualquier error en declaracion de codigo no se detectara en tiempo de compilacion.
/******/
@Bean
public LocalValidatorFactoryBean localValidatorFactoryBean()
throws ClassNotFoundException
{
LocalValidatorFactoryBean validator = new LocalValidatorFactoryBean();
validator.setProviderClass(Class.forName(
"org.hibernate.validator.HibernateValidator"
));
return validator;
}
Establecer la clase de Bean Validation provider, no es necesario en el contenedor de Servlet Tomcat, no aplicaremos esta tecnica.
Mas adelante, veremos como añadir constraints a nuestras clases y entidades. Cuando hacemos esto, es posible indicar un mensaje de error que se asocia a cada constraint o bien un codigo de error. De esta forma, permitimos que dicho mensje de error sea posible de internazionalizar antes de ser mostrado al usuario. Por defecto la internacionalizacion en Bean Validation utiliza bundle files de tipo “ValidationMessages.properties” , “ValidationMessages_[language].properties” , “ValidationMessages_[language]_[region].properties”.... Estos ficheros deben estar en el classpath (/WEB-INF/classes ). Con la implementacion de Bean Validation 1.1, es posible sin embargo, crear nuestro propia internacionalizacion mediante javax.validation.MessageInterpolator .De cualquier forma, en cada caso debemos indicar una la Locale que debe usar el Validator cada vez que este se activa. Spring, nos facilita la tarea de crear nuestro propio “MessageInterpolator” y elimina el tener que preocuparse de pasar cada vez la Locale. Lo que necesitamos es establecer MessageSource en el “LocalValidatorFactoryBean” que declaramos dentro de RootContextConfiguration de manera que de forma automatica provee un interpolator para el MessageSource en concreto:
/*****/
...
@Bean
public MessageSource messageSource()
{
ReloadableResourceBundleMessageSource messageSource = new ReloadableResourceBundleMessageSource();
messageSource.setCacheSeconds(-1);
messageSource.setDefaultEncoding(StandardCharsets.UTF_8.name());
messageSource.setBasenames(
"/WEB-INF/i18n/titles", "/WEB-INF/i18n/messages",
"/WEB-INF/i18n/errors", "/WEB-INF/i18n/validation"
);
return messageSource;
}
@Bean
public LocalValidatorFactoryBean localValidatorFactoryBean()
{
LocalValidatorFactoryBean validator = new LocalValidatorFactoryBean();
validator.setValidationMessageSource(this.messageSource());
return validator;
}
...
/*****/
Una vez configurado “LocalValidatorFactoryBean” para usar nuestro “MessageSource” , podemos crear mensajes de validacion segun la Locale de manera correcta en tiempo de ejecucion.
El concepto de Spring bean post-processors se usa para configurar, personalizar y si necesario reemplazar aquellos beans que existen en nuestra configuracion antes del que el contenedor complete su proceso de arraque. Configurado el org.springframework.beans.factory.config.BeanPostProcessor sus implementaciones se ejecutan antes de que un bean se inyecte dentro de otros beans que dependen de el, por ejemplo:
a) AutowiredAnnotationBeanPostProcessor es un bean del framework que se crea automaticamente cuando configuramos Spring. Controla las anotaciones @Autowire y @Inject y de inyectar dichos valores.
b) InitDestroyAnnotationBeanPostProcessor controla implementaciones de InitializingBean (o metodos anotados con @PostConstruct ) y las implementaciones de DisposableBean (o metodos anotados con @PreDestroy) y ejecuta dichos metodos en la fase apropiada de su ciclo de vida.
c) Algunos post-processors pueden incluso reemplazar el bean. El caso de AnnotationBeanPostProcessor se encarga de buscar aquellos bean con metodos @Async y reemplaza dichos beans con proxies de manera que dichos metodos puedan ser llamados de manera asincrona. La mayoria de los bean post-procesors que necesitamos, como los descritos anteriormente, se crean de manera automatica. Sin embargo, para dar soporte a la validacion de los argumentos de metodos y sus valores de retorno necesitamos crear un org.springframework.validation.beanvalidation .MethodValidationPostProcessor, para que se generen los proxy de la ejecucion los metodos validados. Esta fase no es tan sencialla como la de instanciar un bean MethodValidationPostProcessor ya que por defecto utiliza el validation provider del classpath (sin haber asignado nuestro MessageSource). En su lugar, podemos configurarlo para que use LocalValidatorFactoryBean que creamos anteriormente.
@Bean
public LocalValidatorFactoryBean localValidatorFactoryBean() { ... }
@Bean
public MethodValidationPostProcessor methodValidationPostProcessor()
{
MethodValidationPostProcessor processor =
new MethodValidationPostProcessor();
processor.setValidator(this.localValidatorFactoryBean());
return processor;
}
@Bean
public ObjectMapper objectMapper() { ... }
Este MethodValidationPostProcessor cotrola las clases que se anotan con “@org.springframework .validation.annotation.Validated” o “@javax.validation.executable.ValidateOnExecution” de forma que crea un proxy de dichas clases, de forma que la validacion de los parametros de los metodos se realiza “antes” de la ejecucion del metodo. Y para el valor de retorno, la validacion ocurre justo despues de la ejecucion del metodo.
A diferencia de “MethodValidationPostProcessor” que creamos anteriormente que usa una instancia de Validator, el controlador de objetos form de Spring MVC y la validacion de parametros de los metodos, usan una instancia de Spring Validator. Esto soporte, proveyendo de argumentos de tipo Errors a los metodos que esperan el parametro @Valid ya que la interfaz Errors es mas sencilla de usar que una coleccion de ConstraintViolations. Afortunadamente, “LocalValidatorFactoryBean” implementa ambos interfaces, por defecto Spring MVC, crea una instancia de Spring Validator aparte que oculta la que se creo en la raiz de lel root application context.
Para modificar esta configuracion por defecto, es necesario modificar la clase “ServletContextConfiguration” dicha clase que hereda de “WebMvcConfigurerAdapter”, sobrecargar el metodo getValidator y devolver el validato que habiamos creado en el root application context.
@Inject SpringValidatorAdapter validator;
...
@Override
public Validator getValidator()
{
return this.validator;
}
Con este cambio, Spring MVC usara el Validator que configuramos, para validar el controlador deseado, los parametros de sus metodos y valores de retorno.
Para poder realizar Bean Validation, la aplicacion Spring trabaja con 2 tipos de bean principalmente:
a) POJOs o JavaBeans -es el caso de entidades y objetos de formulario que aparecen como parametro en un metodo o son el resultado que devuelve.
b) Beans propios de Spring como @Controller y @Service que usan los anteriores en sus metodos y tipos de retorno.
Ambos tipos de bean utilizan anotaciones constraint de Bean Validation, pero de distinta manerja. En esta seccion veremos como aplicar annotation constraints a POJO,s. Mas adelante lo haremos sobre Beans propios de Spring.
Aunque es posible definir nuestras propias constraints, el API de Bean Validation trae varias annotation constraints predefinidas, que muy a menudo es suficientemente completo para nuestro uso. Dichas constraints vienen en el paquete javax.validation.constraints .
Aqui mostramos la mayoria de ellas:
1) @Null — Se aplica sobre cualquier tipo de objeto y asegura que el elemento anotado es null
2) @NotNull — Tambien se aplica sobre cualquier tipo de objeto. Se asegura de que el valor es No null.
3) @AssertTrue y @AssertFalse — Se asegura que el valor anotado es true en la primera y false en la segunda. Por ello el parametro anotado o el valor de retorno debe ser de tipo Boolean. Un Boolean con valor null se considera valido en ambas constraints por lo que han de acompañarse de @NotNull si no se acepta dicho valor.
4) @DecimalMax — Declara el valor maximo para un tipo numerico. Puede anotar atributos, parametros de metodo, y metodos de tipos BigDecimal , BigInteger , CharSequence ( String ), byte , Byte , short , Short , int , Int , long , and Long . Los tipos double , Double , float , and Float, no son soportados debido a la cuestion de precision. Una CharSequence se pasa a decimal antes de aplicar la validacion y si se trata de un valor null, se considera valido. Ademas la anotacion acepta un atributo “inclusive=true”, que inidica si la comprobacion debe realizarse de forma inclusiva (menor o igual que) o exclusiva (menor que).
5) @DecimalMin — Igual que la anotacion anterior aplicado al valor menor.
6) @Digits — Se utiliza para asegurar que el elemento anotado es parseable a number (si se trata de una CharSequence) y a continuacion comprueba de que tipo se trata (si es un CharSequence , BigDecimal , BigInteger , byte , Byte , short , Short , int , Int , long , o Long ). El atributo obligatorio “integer” indica el numero maximo numero de digitos enteros en la secuencia, mientras que el atributo “fraction” indica el numero maximo de digitos tras el punto. Los valores nulos son aceptados.
7) @Future — Asegura que el elemento Date o Calendar, contiene un valor mayor al instante actual, ya sea cercano o lejano. Los valores null son aceptados.
8) @Past — Asegura que el elementot Date and Calendar, contiene un valor inferior al instante actual. Valores nulos son aceptados.
9) @Max y @Min — Semejante a @DecimalMax y @DecimalMin, pero no puede aplicarse sobre elementos CharSequence y no tienen el atributo “inclusive”, ya que son siempre inclusive (menor o igual que). Los elementos de valor “null” se consideran validos.
10) @Pattern — Esto nos permite declarar una expresion regular hacia un elemento de tipo CharSequence ( String ) debe cumplir, y considera los valores null como validos. Acepta un flag adicional que soporta un array de elementos del enum Pattern.Flag. Los valores soportados son: Patter.Flag. 1) CANON_EQ — Equivalentes canonicalmente 2) CASE_INSENSITIVE — Mayuscula o minuscula indiferentemente 3) COMMENTS — Permite que existan espacios en blanco y comentarios (“aaa”) dentro del patron 4) DOTALL — Activa el modo todocon puntos 5) MULTILINE — Activa el modo multiline 6) UNICODE_CASE — Activa el modo Unicode 7) UNIX_LINES — Activa el modo unix (CRLF)
11) @Size — Establece los limites inclusivos de @Max y @Min a la longitudo de la CharSequence ( String ), el numero de valores de la Colleccion, el numero de entradas en un Map, o el numero de elelemntos de un array de cualquier tipo.
Como vemos existe una gran cantidad de constraints que podemos usar. Ademas de eso, existen atributos especificos de dichas anotaciones que ya hemos comentado, toda anotacion de constraint tiene ademas el siguiente numero de atributos opcionales. Los cuales deben estar tambien presentes en una constraint propia hayamos cread.
1) message — Este atributo indica que mensaje debe mostrarse al usuario. Si el mensaje esta contenido entre llaves ( message="{employee.firstName.notBlank}" ), el contenido representa un codigo que debe ser localizado. Por defecto apunta a un codigo de mensaje que es diferente para cada tipo de constraint. 2) groups — Se trata de un array de Class que indica que grupo de validacion o grupos pertenece esta constraint. Por defecto si el array esta vacio, esto indica que la constraint pertenece a su grupo por defecto. Mas adelante se explicara que son los grupos de validacion. 3) payload — Otro array de Class, dichas clases deben heredar de javax .validation.Payload . Los Payloads aportan meta-informacion al proveedor de validacion (al Constraint Validator), que debe realizar dicha validacion. Esto hace que los payloads no puedan migrar de un proveedor a otro en las anotations constraints que vienen por defecto (ya que el API no declara typos de payload), sin embargo pueden ser utiles a la hora de construir nuestras propias constraints. Podemos usar los payloads para cualquier cosa dentro de nuestra propia constraint (aportarnos cierta informacion extra).
Para finalizar, todas estas annotation constraints declararn una anotation interna: @List que nos permite aplicar varias constraints encadenadas, para un elemento en concreto. Por ejemplo, podemos anotar un elemento con varios @Max mediante @Max.List.
Para comprender mejor el uso basico de constraints, usaremos el ejemplo del principio de la clase “Customer”, se trata de un POJO y muestra una validacion de las reglas de negocio mediante annotations.
public class Customer
{
private long id;
@NotNull(message = "{validate.customer.firstName}")
private String firstName;
@NotNull(message = "{validate.customer.lastName}")
private String lastName;
private String middleName;
@NotNull(message = "{validate.customer.governmentId}")
private String governmentId;
@NotNull(message = "{validate.customer.birthDate}")
@Past(message = "{validate.customer.birthDate}")
private Date birthDate;
@NotNull(message = "{validate.customer.gender}")
private Gender gender;
@NotNull(message = "{validate.customer.badgeNumber}")
private String badgeNumber;
@NotNull(message = "{validate.customer.address}")
private String address;
@NotNull(message = "{validate.customer.city}")
private String city;
@NotNull(message = "{validate.customer.state}")
private String state;
@NotNull(message = "{validate.customer.phoneNumber}")
private String phoneNumber;
@NotNull(message = "{validate.customer.email}")
@Pattern(
regexp = "^[a-z0-9`!#$%^&*'{}?/+=|_~-]+(\\.[a-z0-9`!#$%^&*'{}?/+=" +
"|_~-]+)*@([a-z0-9]([a-z0-9-]*[a-z0-9])?)+(\\.[a-z0-9]" +
"([a-z0-9-]*[a-z0-9])?)*$",
flags = {Pattern.Flag.CASE_INSENSITIVE},
message = "{validate.customer.email}"
)
private String email;
// mutators and accessors
}
Deberiamos tener en cuenta algunos puntos:
a) La mayoria de los atributos estan anotados con @NotNull, b) No existe sustitucion para la linea “trim().length() > 0”,lo que puede volverse un problema de redundancia de codigo rapidamente. c) La expresion regular para validar el e-mail es bastante grande y puede volverse engorrosa si se usa en varias partes. d) birthDate is se comprueba para verificar que se encuentra en el pasado, no para comprob ar que es mayor de edad, ademas el elemento debe ser de un tipo Date previo a Java 8.
De esta manera, podemos realizar validaciones incluso crear las nuestras propias. Sin embargo hay que tener en cuenta que no es valido para todo tipo de validacion. Ya que a menudo necesitamos comprobar que existe el attributo (acceder a base de datos u otro), y esas tareas requieren una validacion mas manual.
Hasta ahora hemos ido anotando atributos sencllos como Strings mediante las validation constraints. Que ocurre en el caso de que el elemento a validar es un tipo complejo que contiene a su vez elementos anotados con constraints?
En este ejemplo:
public class Helicopter
{
@NotNull
private String name;
@NotNull
private AirPort origin;
@NotNull
private AirPort destination;
@NotNull
private List<Person> crew;
@NotNull
private Person engineer;
@NotNull
private Person pilot;
// mutators and accessors
}
Las clases AirPort y Person de este ejemplo son POJOs con sus propios atributos que estan a su vez anotados con validation constraints. Estos objetos anidados no se validan automaticamente. Para asegurarnos de que se validan, debemos anotar estos atributos como @Valid, lo cual indica que un atributo, parametro, o metodo debe validarse en cascada. that a field, parameter, or method (return value) should result in cascading validation.
public class Helicopter
{
@NotNull
private String name;
@NotNull
@Valid private AirPort origin;
@NotNull
@Valid private AirPort destination;
@NotNull
@Valid private List<Person> crew;
@NotNull
@Valid private Person engineer;
@NotNull
@Valid private Person pilot;
// mutators and accessors
}
Si AirPort o Person, contiene atributos que a su vez estan marcados con @Valid, la validacion continua en profundidad hasta llegar a comprobar todos los valores.
Existe un riesgo, sin embargo, cuando el validator detecta un bucle infinito causado por ejemplo debido a “referencias ciclicas”, de manera que termina la validacion sin detectar error despues de que el circulo de referencias le alcanza.
Los grupos de validacion nos permiten activar y desactivar ciertas constraints segun el grupo al que pertenecen y segun que grupos estan activos en ese momento. Esto es muy similar a los Bean Definition Profiles de Spring. Un grupo se representa a traves de cualquier interfaz de marcado. La interfaz debe de no contener ninguna constantes o metodos ya que no sera utilizados. En su lugar, el objeto de Classe interfaz, representa al grupo cuando se define una constraint. A continuacion, en tiempo de validacion, el Validator aplica unicamente aquellas constraints cuyo grupo de Class se indica cuando se realizo la llamada a uno de los metodos: validate, validateProperty o validateValue
Por ejemplo, consideremos una entrada en varios pasos a partir de un UI, en la cual los atributos se van rellenando en cada pagina. Podriamos desear validar que los valores de atributos sean los correctos en cada paso, pero tambien podriamos querer almacenar todos esos valores en un mismo objeto form. Mediante los groups, resulta sencillo:
public interface UiScreen1 { }
public interface UiScreen2 { }
public interface UiScreen3 { }
public class Form
{
@NotNull(groups = UiScreen1.class)
private String field1;
@NotNull(groups = UiScreen2.class)
private String field2;
@NotNull(groups = UiScreen2.class)
private String field3;
@NotNull(groups = UiScreen3.class)
private String field4;
// mutators and accessors
}
A continuacion, cuando debamos validar, solo es necesario pasar el grupo de class apropiado a cada llamada de Validator, y se aplicaran las constraints que corresponden a dichos grupos. Si usamos javax.validation .groups.Default, si ademas queremos evaluar las constraints sin ningun grupo predefinido.
/*esto seria */ // en metodo para paso 1 Set<ConstraintViolation<Form>> violations = validator.validate(form, Default.class, UiScreen1.class) // para el metodo del paso 2 Set<ConstraintViolation<Form>> violations = validator.validate(form, Default.class, UiScreen1.class, UiScreen2.class) // en metodo para el paso 3 Set<ConstraintViolation<Form>> violations = validator.validate(form, Default.class, UiScreen1.class, UiScreen2.class, UiScreen3.class)
Si una constraint no declara ningun grupo, se toma el grupo por defecto. De la misma manera, si una llamada a validate , validateProperty , o validateValue no contiene ningun grupo aplicara tambien el grupo por defecto.
Los grupos de Validation son ademas utiles para aplicar una misma constraint de manera distinta segun el grupo. Asi @Size.List y @Size, por ejemplo, es posible indicar que un elemento de tipo String debe tener una longitud determinada si se valida por un grupo y otra longitud si se valida por otro grupo (o grupos).
/**ejemplo en el que se aplica una constraint de distintas formas **/
public class BusinessObject
{
@Size.List({
@Size(min = 5, max = 100, groups = {Default.class, Group1.class}),
@Size(min = 20, max = 75, groups = Group2.class)
})
private String value;
// mutators and accessors
}
Como suele ser, Spring simplifica el uso de grupos de validation. En vez de tener que acceder al validador directamente, podemos establecer en una anotacion que grupos deben estar activos al validar un elemento. Veremos mas acerca de esto en la siguiente seccion.
En el lenguaje Java existen reglas acerca de que anotaciones podemos usar y donde, establecido mediante java.lang.annotation.ElementType y los valores establecidos a traves de @java.lang.annotation.Target para una definicion particular de anotacion. Sin embargo, las reglas acerca de donde es posible aplicar las constraints de validacion son mucho mas complejas que las que se soportan de forma nativa. Por ejemplo, las anotaciones de constraint pueden aplicarse a ElementyType.METHOD (y otras) en tiempo de compilacion, pero esto pasa por encima el hecho de que las anotaciones de constraint son solo validas en metodos de instancia y no en metodos static (es una diferencia que ElementType no tiene en cuenta). De la misma manera, las constraints solo son validas en metodos de instancias y no en metodos static, sin embargo el compilador no puede capturar esta diferencia tampoco. Aun mas importante que esto, las distintas constraints se limitan a distintos tipos (no es posible usar @Future sobre Strings por ejemplo), y necesitas una manera de asegurarte que aplicamos estas constraints de forma correcta.
El API “Hibernate Validator” dispone de un procesador de anotaciones que en tiempo de compilacion toma control de cierta parte y evita que dicho codigo compile, si las restricciones explicadas anteriormente no se cumplen. Esto facilita, poder aplicar dichas “constraints de validacion” de manera mas sencilla ya que sino el compilador dara error, lanzando una javax.annotation.ConstraintDeclarationException . Para disponer del annotation processor, necesitamos añadir las siguientes dependencias:
org.hibernate hibernate-validator-annotation-processor 5.1.0.Final compile true
La razon por la que esta dependencia se marca como opcional es que Hibernate Validator no la necesita en tiempo runtime. Solo se llama en tiempo de compilacion, de manera que se detecta el anotation processor existente. La parte positiva de hacerlo asi es que el processor se aplica de forma automatica en la fase build de Maven y en la compilacion desde el IDE. La parte negativa es que las clases se encuentran en el classpath y nuestro IDE nos las ofrecera como opcion.
Existen otras formas de instalar annotation processors dentro de Maven y de nuestro IDE. Por ejempo, es posible añadir la dependencia dentro del plug-in del compilador a usar, en lugar de dentro de las dependencias del proyecto, lo que evita que aparezcan en el classpath, pero nos fuerza a separar anotation processor de nuestro IDE.
