[bv-dev] Method level validation

Gunnar Morling gunnar.morling at googlemail.com
Sun Sep 25 07:07:52 EDT 2011


Hi,

I thought it might be a good idea to provide some structure for the
discussion and hence created
https://hibernate.onjira.com/browse/BVAL-241 as umbrella issue for
method validation.

For the different aspects discussed so far I created the following sub-tasks:

BVAL-241
 |
 |- BVAL-245: Define how method constraints are declared at parameters
and return values
 |
 |- BVAL-244: Extend Validator API with methods for method validation
 |
 |- BVAL-242: Extend the meta-data API to represent method-level constraints
 |
 |- BVAL-232: Support cross-parameter constraints (was "Support
Method-Level constraint declaration")
 |
 |- BVAL-243: Provide a means for specifying method parameter names
 |
 |- BVAL-246: Create TCK tests for method validation

IMO it would be a good idea to discuss the details at the related issues. WDYT?

--Gunnar


2011/9/16 Emmanuel Bernard <emmanuel at hibernate.org>:
> Thanks for the various feedback.
> Here are my thoughts.
>
> We can't rename BeanDescriptor to TypeDescriptor as it would break backward compatibility. Even then, I am not convinced that TypeDescriptor is a better name for BeanDescriptor.
>
> I agree we could revisit cross field validation to see if we could converge on a better approach, I've opened https://hibernate.onjira.com/browse/BVAL-240
>
> On named parameters we have three strategies I think:
> - not address the problem at all and use positional parameters to see what comes up JDK 8's hat (named parameters might not be represented as strings but rather as a typed object)
> - not address the problem in the specification but leave the API open enough for a provider to offer a named parameter friendly API
> - address the problem within the spec (the interface approach seems elegant) hoping for the named parameter to be represented as a String in JDK 8
>
> I tend to like param0, param1 etc rather than arg0, arg1 but that's aesthetic.
>
> One part we have not addressed is how constraints are declared on the method. HV works that way (Gunnar, Hardy correct me if I side track).
>
> Constraints on parameters whose type is a subtype of the accepted types by the constraint are declared directly on the parameter
>
>    void doHarm(@NotEmpty String kittenName);
>
> Constrains on parameters whose type is a constrained bean needs an annotation accepting the targeted groups. It was proposed to use @Valid for such case but recent discussions brought that back on the drawing board.
> https://hibernate.onjira.com/browse/BVAL-208?focusedCommentId=43533#comment-43533
>
> There are a few notions floating around @Valid
>
> 1. cascade validation to nested beans
> 2. translate the validation of group A from the owning bean to validation of the group B on the nested bean (see <https://hibernate.onjira.com/browse/BVAL-208>)
> 3. define the group to validate in a method level validation
>
> About 3., I wonder if this should be part of Bean Validation or be part of the interception framework. In other words:
>
> * should it be an annotation provided / proposed by Bean Validation and recognized by interception techs like CDI, @Inject, Spring, AspectJ etc
> * should each interception tech provide its own annotation to specify the targeted group(s)
>
> Emmanuel
>
> On 6 sept. 2011, at 12:16, Emmanuel Bernard wrote:
>
>> 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
>



More information about the beanvalidation-dev mailing list