[bv-dev] Method level validation

[Gerhard Petracek]

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

[1]
https://svn.apache.org/repos/asf/incubator/bval/tags/0.3-incubating/bval-jsr303/src/main/java/org/apache/bval/jsr303/extensions/MethodValidator.java

2011/9/6 Gunnar Morling <gunnar.morling at 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 at 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20110907/4b19d3f2/attachment-0001.html