12:56 p.m.
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.
Any thoughts?
--Gunnar
[1] http://beanvalidation.org/latest-draft/spec/#d0e9636
1:27 p.m.
On 15 Jan 2013, at 7:56 PM, Gunnar Morling <gunnar(a)hibernate.org> wrote:
As you know we're likely going to exclude getter methods from
method validation by default
:-(
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.
But this would still mean that there is an option in BV to turn on/off the validation of
getters, right? Or do you suggest that BV is actually agnostic of which type of method it
validates and it is the integration framework which is responsible for excluding getters.
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.
Sounds interesting.
--Hardy
1:42 p.m.
2013/1/15 Hardy Ferentschik <hardy(a)hibernate.org>
On 15 Jan 2013, at 7:56 PM, Gunnar Morling <gunnar(a)hibernate.org> wrote:
> As you know we're likely going to exclude getter methods from method
validation by default
:-(
Yeah, I'd also prefer to include them by default, but there seem to be
powers working against us ;)
> 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.
But this would still mean that there is an option in BV to turn on/off the
validation of getters, right? Or do you suggest that BV is actually
agnostic of which type of method it validates and it is the integration
framework which is responsible for excluding getters.
Yes, that's what I had in mind. BV as the validation engine should validate
any method it is asked to validate, and the integration framework should
define/configure for which methods this is the case. For CDI we would still
define the details, but not as part of the validation logic but within the
CDI integration chapter of the 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.
Sounds interesting.
--Hardy
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
3:08 a.m.
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> 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.
Any thoughts?
--Gunnar
[1] http://beanvalidation.org/latest-draft/spec/#d0e9636
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
3:15 a.m.
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> 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> 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.
Any thoughts?
--Gunnar
[1] http://beanvalidation.org/latest-draft/spec/#d0e9636
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
3:38 a.m.
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> 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> 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> 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
10:24 a.m.
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(a)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(a)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(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
12:34 p.m.
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(a)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(a)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(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
3:17 p.m.
On Thursday, 17 January 2013, Gunnar Morling <gunnar(a)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(a)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(a)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(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
4541
days inactive
4543
days old
beanvalidation-dev@lists.jboss.org
8 comments
5 participants
participants (5)
-
Emmanuel Bernard -
Gunnar Morling -
Hardy Ferentschik -
Michael Nascimento -
Rich Midwinter