Re: [bv-dev] Method level validation

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