[bv-dev] Method level validation

[Gunnar Morling]

> 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?

Sebastian I'm vaguely remembering you're having some sort of pluggable
approach in OVal for parameter name providers. Maybe you could provide
some more details?

--Gunnar


> Regards
> Richard
>
> On 7 September 2011 19:49, Gerhard Petracek <gerhard.petracek at 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
>> [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
>>
>>
>> _______________________________________________
>> 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
>
>