[bv-dev] Method level validation

Wed Sep 7 15:50:22 EDT 2011

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 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20110907/9db6d593/attachment.html 