Hi,

> Gunnar, could to take the lead on the Hibernate Validator version? You know this area best.

Sure. What we have in HV [1], [2] is pretty much based on appendix C
of BV 1.0 [3]. More specifically that is:

* IF MethodValidator:

public interface MethodValidator {

       <T> Set<MethodConstraintViolation<T>> validateParameter(T object,
Method method, Object parameterValue, int parameterIndex, Class<?>...
groups);

       <T> Set<MethodConstraintViolation<T>> validateAllParameters(T object,
Method method, Object[] parameterValues, Class<?>... groups);

       <T> Set<MethodConstraintViolation<T>> validateReturnValue(T object,
Method method, Object returnValue, Class<?>... groups);

       TypeDescriptor getConstraintsForType(Class<?> clazz);
}

In BV these methods should go into javax.validation.Validator (plus
validateConstructorParameters or similar).

* IF MethodConstraintViolation which extends ConstraintViolation by
adding getMethod(), getParameterIndex() etc. to specify the source of
a violation.

* MethodConstraintViolationException, wrapping a set of
MethodConstraintViolations and to be thrown by integrators of the
method validation feature.

* Extension to the constraint meta data API based on IF TypeDescriptor:

public interface TypeDescriptor extends ElementDescriptor {

       boolean isTypeConstrained();

       Set<MethodDescriptor> getConstrainedMethods();

       MethodDescriptor getConstraintsForMethod(String methodName,
Class<?>... parameterTypes);

       BeanDescriptor getBeanDescriptor();
}

In BV 1.1 this should be merged with BeanDescriptor (which in turn
should be renamed to TypeDescriptor IMO as it isn't restricted to
JavaBeans any more).

* Extension to the programmatic API [4] allowing to specify method
constraints programmatically like this:

ConstraintMapping mapping = new ConstraintMapping();
mapping.type( Car.class )
   .method( "drive", String.class, Integer.class )
       .parameter( 0 )
           .constraint( new NotNullDef() )
           .constraint( new MinDef().value ( 1 ) )
       .returnValue()
           .valid();

HibernateValidatorConfiguration config = Validation.byProvider(
HibernateValidator.class ).configure();
config.addMapping( mapping );
Validator validator = config.buildValidatorFactory().getValidator();

What we don't have:

* constructor validation

* cross-parameter validation as discussed in BV-232.

* parameter constraints may only be specified at the "lowest version"
of an overridden method, see [5]. Though I don't think that this
restriction is really an issue.

* ability to specify parameter names, see [6].

@Hardy: Do see anything missing?

--Gunnar


[1] HV reference guide on method validation:
http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html/validator-specifics.html#validator-customoptions-methodvalidation
[2] HV's method validation API:
http://docs.jboss.org/hibernate/stable/validator/api/index.html?org/hibernate/validator/method/package-summary.html
[3] BV 1.0, Appendix C:
http://beanvalidation.org/1.0/spec/#appendix-methodlevelvalidation
[4] HV's programmatic constraint API:
http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/#programmaticapi
[5] Using method constraints in type hierarchies:
http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_single/#d0e3267
[6] Specifying parameter names: https://hibernate.onjira.com/browse/HV-409


2011/9/6 Emmanuel Bernard <emmanuel@hibernate.org>:

> While we still decide what to do in which order, I'd like to start thinking about method level validation in parallel.
>
> Probably the biggest feature for this new round ( http://beanvalidation.org/roadmap/ ) is method level validation.
>
> ## Goal
>
> Offer the ability to:
>
> - annotate method and constructor parameters and return values with Bean Validation constraints.
> - provide validation methods to validate a method / constructor given a set of parameters
>
> This set of methods will be used by framework controlling the method execution cycle (CDI, JAX-RS, aspect oriented frameworks etc).
>
> https://hibernate.onjira.com/browse/BVAL-232
>
> We need to explore this feature to clarify what we want to support, how we want to support it, how it integrates with Bean Validation 1.0.
>
> ## Usefulness
>
> This method will be useful to various other specifications including CDI and JAX-RS. That's why I'd like to stabilize this feature as early as possible.
>
> ## Proposals
>
> Hibernate Validator has an implementation of such feature and I am sure OVal, Apache Bean Validation and others have something similar. Let's start with describing what we have and start the discussion from here.
>
> Gunnar, could to take the lead on the Hibernate Validator version? You know this area best.
>
> Emmanuel
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev