<div dir="ltr">> <span style="font-family:arial,sans-serif;font-size:13px">I guess preferring consistency across projects rather than within them.</span><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div><font face="arial, sans-serif">Ok, I see.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">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 </font><span style="font-family:arial,sans-serif">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.)?</span></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">To make a case against my own argument though, I think there is </font><span style="font-family:arial,sans-serif">right now </span><span style="font-family:arial,sans-serif">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.</span></div>
<div><span style="font-family:arial,sans-serif"><br></span></div><div style><span style="font-family:arial,sans-serif">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.</span></div>
<div><span style="font-family:arial,sans-serif"><br></span></div><div style><span style="font-family:arial,sans-serif">--Gunnar</span></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">2013/1/16 Rich Midwinter <span dir="ltr"><<a href="mailto:rich.midwinter@gmail.com" target="_blank">rich.midwinter@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
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.<span><font color="#888888"><br>
<br>Rich.</font></span><div><div><br><br><br>On Wednesday, 16 January 2013, Michael Nascimento <<a href="mailto:misterm@gmail.com" target="_blank">misterm@gmail.com</a>> wrote:<br>
> I think BV should fully specify the behaviour, i.e., it should be some<br>> sort of flag supported by our spec, not the technology consuming it.<br>><br>> Regards,<br>> Michael<br>><br>> On Wed, Jan 16, 2013 at 7:08 AM, Emmanuel Bernard<br>
> <<a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>> wrote:<br>>> Trying to summarize here: should the mechanism used to choose which method<br>>> is to be validated (all, non_getter, off) be defined by the integration<br>
>> technology or should it be defined by the Bean Validation spec.<br>>><br>>> I see Gunnar's argument and I am not sure where to stand. My arguments<br>>> against Gunnar's proposal are the following:<br>
>><br>>> - the behavior would be different depending on the integration technology<br>>> used (Spring, CDI, JSR-303, possibly even managed beans - not sure of the<br>>> consequences for managed beans)<br>
>> - I find it easier for a user to have all the control tools at his disposal<br>>> from within the spec. In particular the global flag to set the default value<br>>> naturally fits in validation.xml which would not really be possible if the<br>
>> integration technology takes ownership of this.<br>>><br>>> You know our mantra has always been consistency across the whole app<br>>> development. Like a famous ring,<br>>><br>>> One Way to rule them all, One Way to constraint them,<br>
>> One Way to validate them all and in the EE spec bind them.<br>>><br>>> On the other hands, inheritance rules for @ValidateOnCall across inherited<br>>> methods, super types and the potentially future package level is really hard<br>
>> to define. But I don't think the integration technologies define them in a<br>>> clear way either for our needs at least. In CDI, you can find the rules in<br>>> chapter 4. <a href="http://docs.jboss.org/cdi/spec/1.1-PRD/pdf/cdi-spec.pdf" target="_blank">http://docs.jboss.org/cdi/spec/1.1-PRD/pdf/cdi-spec.pdf</a>. It's<br>
>> very much "chose whatever you want" IMO.<br>>><br>>> Please, express your feedback even if not strong on the matter, we need to<br>>> make a decision quickly. The deadline is approaching fast.<br>
>><br>>> Emmanuel<br>>><br>>> On 15 janv. 2013, at 19:56, Gunnar Morling <<a href="mailto:gunnar@hibernate.org" target="_blank">gunnar@hibernate.org</a>> wrote:<br>>><br>>> Hi all,<br>
>><br>
>> As you know we're likely going to exclude getter methods from method<br>>> validation by default and provide means of configuring the exact behavior<br>>> (e.g. to have getters validated for individual types).<br>
>><br>>> The question is now how this configuration should look like and where it<br>>> should be described. I think there is two separate components here:<br>>><br>>> 1) BV which provides the logic/engine for performing method validation<br>
>> 2) Technologies integrating the method validation feature, e.g. CDI, Spring<br>>> etc. For CDI, the behavior of this integration is described in the BV spec<br>>> (section 10.2 [1]) as per the Java EE conventions. For e.g. Spring, the<br>
>> behavior would be described in the Spring documentation.<br>>><br>>> Regarding the configuration of including/excluding getters, one option would<br>>> be to define a BV-specific mechanism for the configuration of (e.g. a global<br>
>> option in validation.xml and/or an annotation like @ValidateOnCall). This<br>>> mechanism would have to be queried by the technologies integrating with<br>>> method validation.<br>>><br>>> Alternatively, whether to include/exclude getters could be part of the<br>
>> configuration of 2). For CDI, this might e.g. happen by adding an attribute<br>>> "validateGetters()" to the interceptor binding annotation triggering method<br>>> validation, while e.g. Spring users might define an appropriate point cut<br>
>> expression matching all those methods they want to validate. For CDI we<br>>> would again describe the exact means in section 10.2 of the BV spec.<br>>><br>>> Personally I'd favor the latter approach for the following reasons:<br>
>><br>>> * The configuration of which methods to intercept is IMO a natural<br>>> responsibility of integrating technologies<br>>> * Integrating technologies already define mechanisms for handling things<br>
>> like inheritance of metadata (e.g. configuration given on super-types),<br>>> resolving conflicts of global vs. local metadata etc. It makes sense to<br>>> reuse these mechanisms instead of defining alternative rules in the BV spec.<br>
>><br>>> On the downside, one would be limited to the means of configuration provided<br>>> by a particular integrating technology. E.g. I'm not aware of a way of<br>>> global configuration options in CDI (we might try to get this changed,<br>
>> though). I still think this should be addressed in the integrating<br>>> technology instead of BV.<br>>><br>>> An
</div></div><br>_______________________________________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
<br></blockquote></div><br></div></div>