[bv-dev] Method level validation

[Emmanuel Bernard]

Thanks,

I think what works best is an initial discussion by email followed by a proposal (spec change) and refinements that can be discussed either on this mailing list or on the specific BVAL elements.
I must admit following all BVAL changes is not as easy as it should and I expect many here will only follow this mailing list. So fine grained discussions on BVAL elements is good as long as they are retrofitted into the proposal.

On 25 sept. 2011, at 13:07, Gunnar Morling wrote:

> 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
>> 
> 
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev