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.<br><br>Rich.<br><br><br>On Wednesday, 16 January 2013, Michael Nascimento <<a href="mailto:misterm@gmail.com">misterm@gmail.com</a>> wrote:<br>
> I think BV should fully specify the behaviour, i.e., it should be some<br>> sort of flag supported by our spec, not the technology consuming it.<br>><br>> Regards,<br>> Michael<br>><br>> On Wed, Jan 16, 2013 at 7:08 AM, Emmanuel Bernard<br>
> <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>> wrote:<br>>> Trying to summarize here: should the mechanism used to choose which method<br>>> is to be validated (all, non_getter, off) be defined by the integration<br>
>> technology or should it be defined by the Bean Validation spec.<br>>><br>>> I see Gunnar's argument and I am not sure where to stand. My arguments<br>>> against Gunnar's proposal are the following:<br>
>><br>>> - the behavior would be different depending on the integration technology<br>>> used (Spring, CDI, JSR-303, possibly even managed beans - not sure of the<br>>> consequences for managed beans)<br>
>> - I find it easier for a user to have all the control tools at his disposal<br>>> from within the spec. In particular the global flag to set the default value<br>>> naturally fits in validation.xml which would not really be possible if the<br>
>> integration technology takes ownership of this.<br>>><br>>> You know our mantra has always been consistency across the whole app<br>>> development. Like a famous ring,<br>>><br>>> One Way to rule them all, One Way to constraint them,<br>
>> One Way to validate them all and in the EE spec bind them.<br>>><br>>> On the other hands, inheritance rules for @ValidateOnCall across inherited<br>>> methods, super types and the potentially future package level is really hard<br>
>> to define. But I don't think the integration technologies define them in a<br>>> clear way either for our needs at least. In CDI, you can find the rules in<br>>> chapter 4. <a href="http://docs.jboss.org/cdi/spec/1.1-PRD/pdf/cdi-spec.pdf">http://docs.jboss.org/cdi/spec/1.1-PRD/pdf/cdi-spec.pdf</a>. It's<br>
>> very much "chose whatever you want" IMO.<br>>><br>>> Please, express your feedback even if not strong on the matter, we need to<br>>> make a decision quickly. The deadline is approaching fast.<br>
>><br>>> Emmanuel<br>>><br>>> On 15 janv. 2013, at 19:56, Gunnar Morling <<a href="mailto:gunnar@hibernate.org">gunnar@hibernate.org</a>> wrote:<br>>><br>>> Hi all,<br>>><br>
>> As you know we're likely going to exclude getter methods from method<br>>> validation by default and provide means of configuring the exact behavior<br>>> (e.g. to have getters validated for individual types).<br>
>><br>>> The question is now how this configuration should look like and where it<br>>> should be described. I think there is two separate components here:<br>>><br>>> 1) BV which provides the logic/engine for performing method validation<br>
>> 2) Technologies integrating the method validation feature, e.g. CDI, Spring<br>>> etc. For CDI, the behavior of this integration is described in the BV spec<br>>> (section 10.2 [1]) as per the Java EE conventions. For e.g. Spring, the<br>
>> behavior would be described in the Spring documentation.<br>>><br>>> Regarding the configuration of including/excluding getters, one option would<br>>> be to define a BV-specific mechanism for the configuration of (e.g. a global<br>
>> option in validation.xml and/or an annotation like @ValidateOnCall). This<br>>> mechanism would have to be queried by the technologies integrating with<br>>> method validation.<br>>><br>>> Alternatively, whether to include/exclude getters could be part of the<br>
>> configuration of 2). For CDI, this might e.g. happen by adding an attribute<br>>> "validateGetters()" to the interceptor binding annotation triggering method<br>>> validation, while e.g. Spring users might define an appropriate point cut<br>
>> expression matching all those methods they want to validate. For CDI we<br>>> would again describe the exact means in section 10.2 of the BV spec.<br>>><br>>> Personally I'd favor the latter approach for the following reasons:<br>
>><br>>> * The configuration of which methods to intercept is IMO a natural<br>>> responsibility of integrating technologies<br>>> * Integrating technologies already define mechanisms for handling things<br>
>> like inheritance of metadata (e.g. configuration given on super-types),<br>>> resolving conflicts of global vs. local metadata etc. It makes sense to<br>>> reuse these mechanisms instead of defining alternative rules in the BV spec.<br>
>><br>>> On the downside, one would be limited to the means of configuration provided<br>>> by a particular integrating technology. E.g. I'm not aware of a way of<br>>> global configuration options in CDI (we might try to get this changed,<br>
>> though). I still think this should be addressed in the integrating<br>>> technology instead of BV.<br>>><br>>> An