Re: [bv-dev] Configuring method validation

I guess preferring consistency across projects rather than within them.

I'm torn on this one, Gunnar makes a good argument as ever. Defined by the BV spec would get my vote though, I guess preferring consistency across projects rather than within them. Rich. On Wednesday, 16 January 2013, Michael Nascimento <misterm(a)gmail.com&gt; wrote: > I think BV should fully specify the behaviour, i.e., it should be some > sort of flag supported by our spec, not the technology consuming it. > > Regards, > Michael > > On Wed, Jan 16, 2013 at 7:08 AM, Emmanuel Bernard > <emmanuel(a)hibernate.org&gt; wrote: >> Trying to summarize here: should the mechanism used to choose which method >> is to be validated (all, non_getter, off) be defined by the integration >> technology or should it be defined by the Bean Validation spec. >> >> I see Gunnar's argument and I am not sure where to stand. My arguments >> against Gunnar's proposal are the following: >> >> - the behavior would be different depending on the integration technology >> used (Spring, CDI, JSR-303, possibly even managed beans - not sure of the >> consequences for managed beans) >> - I find it easier for a user to have all the control tools at his disposal >> from within the spec. In particular the global flag to set the default value >> naturally fits in validation.xml which would not really be possible if the >> integration technology takes ownership of this. >> >> You know our mantra has always been consistency across the whole app >> development. Like a famous ring, >> >> One Way to rule them all, One Way to constraint them, >> One Way to validate them all and in the EE spec bind them. >> >> On the other hands, inheritance rules for @ValidateOnCall across inherited >> methods, super types and the potentially future package level is really hard >> to define. But I don't think the integration technologies define them in a >> clear way either for our needs at least. In CDI, you can find the rules in >> chapter 4. http://docs.jboss.org/cdi/spec/1.1-PRD/pdf/cdi-spec.pdf. It's >> very much "chose whatever you want" IMO. >> >> Please, express your feedback even if not strong on the matter, we need to >> make a decision quickly. The deadline is approaching fast. >> >> Emmanuel >> >> On 15 janv. 2013, at 19:56, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: >> >> Hi all, >> >> As you know we're likely going to exclude getter methods from method >> validation by default and provide means of configuring the exact behavior >> (e.g. to have getters validated for individual types). >> >> 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. >> >> 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. >> >> On the downside, one would be limited to the means of configuration provided >> by a particular integrating technology. E.g. I'm not aware of a way of >> global configuration options in CDI (we might try to get this changed, >> though). I still think this should be addressed in the integrating >> technology instead of BV. >> >> An _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev