<div dir="ltr">Answers inline.<br><div class="gmail_extra"><br><div class="gmail_quote">2013/1/30 Emmanuel Bernard <span dir="ltr"><<a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</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">The discussion was thankfully captured in BVAL-332<br>
<br>
> We are agreeing that @ConvertGroup can only be defined when @Valid is defined. This solves the problem of defining @ConvertGroup several times in the class hierarchy and avoid the problem of violating the Liskov substitution principle:<br>
> @Valid can only be defined at the top level for params as per the existing rules<br>
> @Valid can be defined on return values<br>
> We are adding a rule that enforce that @Valid can only be defined once per class hierarchy. This solves again the risk of defining it twice and thus being able to define @ConvertGroup twice which would trigger the Liskov BSOD.<br>
> There is one remaining problem: In case of parallel interfaces defining the same method, the return value can host constraints which means we could define @Valid on both interfaces and thus have parallel @ConvertGroup rules and contradictions. The easy solution is to add a provision rule forbidding to have @ConvertGroup twice in this case.<br>
> If we find a better solution over the week end we can change that<br>
<br>
To me defined in the same class hierarchy means a direct line between a<br>
method and an overridden method because we are precisely talking about<br>
methods and not the whole class. But two methods with the same sig in<br>
parallel interfaces implemented by a class does not seem to fall into<br>
this category.<br></blockquote><div><br></div><div style>Ah, ok, this definition of "class hierarchy" was not apparent to me. I assumed this would also cover the parallel interfaces case. Maybe we should explicitly mention this.</div>
<div style> </div><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">
<br>
interface Baz1 {<br>
@Valid<br>
public Var getBar();<br>
}<br>
<br>
class Baz2 {<br>
@Valid<br>
public Var getBar();<br>
}<br>
<br>
class Baz3 extends Baz2 implements Baz1 {<br>
}<br>
<br>
I do think this is a valid usage of @Valid but would be dangerous if<br>
compound with @ConvertGroup. That's why there is this special provision<br>
in 4.4.5<br>
<br>
> Likewise, if a sub type overrides/implements a method originally<br>
> defined in several parallel types of the hierarchy [...] and if that<br>
> method's return value has been marked for cascading validation in one<br>
> of the parallel types, no group conversion rule may be declared for<br>
> that method's return value in the parallel types of the hierarchy.<br></blockquote><div> <br></div><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">
So what about your example, clearly it falls into that rule and this<br>
@ConvertGroup is not allowed but is it legal to @Override parallel<br>
methods marked with @Valid. I'm tempted to say yes. Thoughts?<br></blockquote><div><br></div><div>Yes, that makes sense given the above definition of "class hierarchy".</div><div><br></div><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">
But the crux is that I'm not sure we can call these two parallel methods<br>
to be a single one and thus be defined several times in the class<br>
hierarchy even if it is overridden later in by Foo3.<br>
<br>
Anything I should change in the spec to make that clearer?<br></blockquote><div><br></div><div style>I think it would help to explicitly mention that several "parallel" return value @Valid annotations are legal in the rule in 4.5.5 ("<span style="font-family:arial,sans-serif;font-size:13px">One must not mark a method return value for cascaded validation more than once in a class hierarchy...").</span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">A related question is what the implications of these rules are for the specification of @Valid on properties (getter methods).</span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">I think in 1.0 it was legal to annotate a super-type and an overriding getter both with @Valid (at least it wasn't explicitly declared illegal AFAICS), but we would change that in 1.1, at least in the context of method validation. Maybe we should add a note on this, too.</span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><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">
<span class=""><font color="#888888"><br>
Emmanuel<br></font></span></blockquote><div><br></div><div style>Thanks,</div><div style><br></div><div style>--Gunnar</div><div style> </div><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">
<span class=""><font color="#888888">
</font></span><div class=""><div class="h5"><br>
On Tue 2013-01-29 9:24, Gunnar Morling wrote:<br>
> Ok, thanks. How is it with specifying @Valid on parallel types:<br>
><br>
> interface IFoo1 {<br>
> @Valid<br>
> public Bar getBar() {}<br>
> }<br>
><br>
> interface IFoo2 {<br>
> @Valid<br>
> public Bar getBar() {}<br>
> }<br>
><br>
> class FooImpl implements IFoo1, IFoo2 {<br>
> @Override<br>
> public Bar getBar() {}<br>
> }<br>
><br>
> Is this legal? The wording in 4.5.5 seems a bit unclear:<br>
><br>
> > One must not mark a method return value for cascaded validation more than<br>
> once in a class hierarchy.<br>
><br>
> This would render the situation above illegal. But then it goes on:<br>
><br>
> > In other words, sub types (be it sub classes/interfaces or interface<br>
> implementations) cannot mark the return value for cascaded validation if<br>
> the return value has already been marked on a super type or interface.<br>
><br>
> This describes only the subtype situation, not addressing the situation<br>
> above and thus implying that it is legal. Maybe we just remove the second<br>
> sentence? I think it is also understandable on its own right due to the<br>
> other cases before.<br>
><br>
> Note that constraint mappings are explicitly forbidden for parallel<br>
> hierarchies in section 4.4.5.<br>
><br>
> Emmanuel, what was our intention when forbidding to specify @Valid several<br>
> times? Forbidding several occurrences of @ConvertGroup makes sense to me<br>
> due to the LSP, but several @Valid don't seem problematic to me.<br>
><br>
> Or was it to "transitively" cover the @ConvertGroup case since we also say<br>
> that @ConvertGroup may only be given where @Valid is specified?<br>
><br>
> I think it would make sense to either<br>
><br>
> * Forbid several occurrences of @Valid (subtypes, parallel hierarchies);<br>
> Allow @ConvertGroup only where @Valid is given; Don't have additional rules<br>
> for @ConvertGroup<br>
><br>
> OR<br>
><br>
> * Allow several occurrences of @Valid; Allow @ConvertGroup only where<br>
> @Valid is given; Forbid several occurrences of @ConvertGroup (subtypes,<br>
> parallel hierarchies)<br>
><br>
> WDYT?<br>
><br>
> --Gunnar<br>
><br>
><br>
> 2013/1/28 Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>><br>
><br>
> > Yes that was the idea to only offer the first variant as valid. If the<br>
> > spec is too unclear open an issue.<br>
> ><br>
> > On 28 janv. 2013, at 17:51, Gunnar Morling <<a href="mailto:gunnar@hibernate.org">gunnar@hibernate.org</a>> wrote:<br>
> ><br>
> > > Emmanuel, all,<br>
> > ><br>
> > > I need a short confirmation related to the definition of group<br>
> > conversions for the return value of an overriding method. IIUC, the<br>
> > following is legal:<br>
> > ><br>
> > > Class Foo {<br>
> > > public Bar getBar() {}<br>
> > > }<br>
> > ><br>
> > > Class SubFoo extends Foo {<br>
> > ><br>
> > > @Valid<br>
> > > @ConvertGroup(from=..., to=...)<br>
> > > @Override<br>
> > > public Bar getBar() {}<br>
> > > }<br>
> > ><br>
> > > That is, SubFoo can define a group conversion for the return value as<br>
> > @Valid itself is added in SubFoo only. It would be illegal if @Valid was<br>
> > given in Foo, too.<br>
> > ><br>
> > > I think that makes sense since LSP is not violated by the first variant,<br>
> > while it would in the second (a user of Foo wouldn't be aware of the<br>
> > applying conversions).<br>
> > ><br>
> > > Right?<br>
> > ><br>
> > > Thanks,<br>
> > ><br>
> > > --Gunnar<br>
> > ><br>
> > > _______________________________________________<br>
> > > beanvalidation-dev mailing list<br>
> > > <a href="mailto:beanvalidation-dev@lists.jboss.org">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>
> > _______________________________________________<br>
> > beanvalidation-dev mailing list<br>
> > <a href="mailto:beanvalidation-dev@lists.jboss.org">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>
<br>
> _______________________________________________<br>
> beanvalidation-dev mailing list<br>
> <a href="mailto:beanvalidation-dev@lists.jboss.org">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>
_______________________________________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org">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>
</div></div></blockquote></div><br></div></div>