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@gmail.com> 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@hibernate.org> 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@hibernate.org> 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