Re: [bv-dev] Method level validation

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(a)hibernate.org&gt;: > 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#comme... > > 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev