[bv-dev] Method level validation

Wed Sep 7 16:29:11 EDT 2011

Answers inline.

--Gunnar

2011/9/7 Gerhard Petracek <gerhard.petracek at gmail.com>:
> 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>.

In HV we're using the passed object as root bean in the resulting
ConstraintViolation. How is that in Apache Validation, is the root
bean null in that case? Btw. how are you handling property path's for
method validation? In HV we've path's like this:
"CustomerRepository#persistCustomer(arg0).address.city".

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

Yepp, that's probably not worth a breaking change.

> @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)

I understand these concerns. What would you prefer for naming? Maybe
we could have an own annotation?

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