[bv-dev] Configuring method validation

[Gunnar Morling]

2013/1/15 Hardy Ferentschik <hardy at hibernate.org>

>
> On 15 Jan 2013, at 7:56 PM, Gunnar Morling <gunnar at hibernate.org> wrote:
>
> > As you know we're likely going to exclude getter methods from method
> validation by default
>
> :-(
>

Yeah, I'd also prefer to include them by default, but there seem to be
powers working against us ;)


> > The question is now how this configuration should look like and where it
> should be described. I think there is two separate components here:
> >
> > 1) BV which provides the logic/engine for performing method validation
> > 2) Technologies integrating the method validation feature, e.g. CDI,
> Spring etc. For CDI, the behavior of this integration is described in the
> BV spec (section 10.2 [1]) as per the Java EE conventions. For e.g. Spring,
> the behavior would be described in the Spring documentation.
> >
> > Regarding the configuration of including/excluding getters, one option
> would be to define a BV-specific mechanism for the configuration of (e.g. a
> global option in validation.xml and/or an annotation like @ValidateOnCall).
> This mechanism would have to be queried by the technologies integrating
> with method validation.
> >
> > Alternatively, whether to include/exclude getters could be part of the
> configuration of 2). For CDI, this might e.g. happen by adding an attribute
> "validateGetters()" to the interceptor binding annotation triggering method
> validation, while e.g. Spring users might define an appropriate point cut
> expression matching all those methods they want to validate. For CDI we
> would again describe the exact means in section 10.2 of the BV spec.
>
> But this would still mean that there is an option in BV to turn on/off the
> validation of getters, right? Or do you suggest that BV is actually
>  agnostic of which type of method it validates and it is the integration
> framework which is responsible for excluding getters.
>

Yes, that's what I had in mind. BV as the validation engine should validate
any method it is asked to validate, and the integration framework should
define/configure for which methods this is the case. For CDI we would still
define the details, but not as part of the validation logic but within the
CDI integration chapter of the spec.


>
> > Personally I'd favor the latter approach for the following reasons:
> >
> > * The configuration of which methods to intercept is IMO a natural
> responsibility of integrating technologies
> > * Integrating technologies already define mechanisms for handling things
> like inheritance of metadata (e.g. configuration given on super-types),
> resolving conflicts of global vs. local metadata etc. It makes sense to
> reuse these mechanisms instead of defining alternative rules in the BV spec.
>
> Sounds interesting.
>
> --Hardy
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20130115/1d64698d/attachment.html