Cross parameter validation seems like a potentially thorny issue we should try and consider alongside this to me as well. (Approach 2a on BVAL-232 seems reasonable?)

I'm not so keen on @Named for identifying the parameters, for the same reasons as Gerhard mentions but also just because the parameter name becomes duplicated. However it looks as though Kevin has suggested an alternative in a comment on Gunnar's reference [6] and that there may be an existing implementation in at least OVal too?

Regards
Richard


On 7 September 2011 19:49, Gerhard Petracek <gerhard.petracek@gmail.com> wrote:
hi,

@MethodValidator
+1 for the concept in general
however, if there isn't a reason for using T object compared to Class<T> clazz (see [1]) as parameter, i would prefer Class<T>.

@BeanDescriptor (renaming it to TypeDescriptor)
it's a type-safe change - but still -1

@named parameters:
(for the spec.) i don't like the idea to re-use @Named for it (the package javax.inject and therefore the dependency in general look strange from the perspective of bv)
imo we should re-visit cross-field validation. a solution for it might influence this topic as well (to keep it consistent).

regards,
gerhard


2011/9/6 Gunnar Morling <gunnar.morling@googlemail.com>
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


_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev