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