[bv-dev] Configuring method validation

[Emmanuel Bernard]

For you info, I have let the problem of inheritance settle in my mind.
I don't think @ValidateOnCall placed on a superclass should be considered
when processing a subclass. In other words, I don't think
@ValidateOnCall should be @Inherited.

My reasoning is that type level marking is really a shortcut to avoid
marking all getters in a class. It seems fine and clearer to have to
repeat it on subclasses.

Also Gunnar made a compelling argument not to inherit @ValidateOnCall
from interfaces one implements.

That solves most of my problems including future inclusion of package
level @ValidateOnCall if needed while keeping rules simples.

I understand that my "reasoning" is close to a judgment call though.
Does anyone has a strong reason to make @ValidateOnCall @Inherited?

Emmanuel

On Thu 2013-01-17 17:24, Gunnar Morling 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.)?
> 
> 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 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >
> >

> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev