[bv-dev] Configuring method validation

[Rich Midwinter]

On Thursday, 17 January 2013, Gunnar Morling <gunnar at hibernate.org> wrote:
>> I guess preferring consistency across projects rather than within them.
> Ok, I see.
> I'd expect a user typically to do several projects using one and the same
of these integration technologies instead of using Bean Validation once
with CDI, once with Spring etc. So wouldn't it be beneficial for a user for
the sake of consistency to configure which methods are subject to
interception according to the paradigms of their platform (CDI, Spring
etc.)?


Yes, but I think it's a balance; I'd probably expect more of a mixed
picture rather than all one framework or no framework used more than once.
Mileage will undoubtedly vary though and I certainly don't hold a strong
preference on this thin basis.


> To make a case against my own argument though, I think there is right
now no way of globally configuring things such as "include getters" in CDI.
This could be done using e.g. a property in beans.xml, but AFAIK there is
no such thing as properties there as of today. Not sure whether time allows
to try to get this in.
> Advantages I see of leaving this to integration technologies is that we
don't have to deal with inheritance rules of the related configuration and
from a BV perspective all methods would be handled equally during
validation.
> --Gunnar
>
> 2013/1/16 Rich Midwinter <rich.midwinter at gmail.com>
>>
>> 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 at 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 at 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 at 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 configuratio
>> _______________________________________________
>> 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/20130117/abc51e34/attachment.html