<div dir="ltr">Ok, thanks. How is it with specifying @Valid on parallel types:<div><br></div><div><div style="font-family:arial,sans-serif;font-size:13px">interface IFoo1 {</div><div style="font-family:arial,sans-serif;font-size:13px">
@Valid<br></div><div style="font-family:arial,sans-serif;font-size:13px"> public Bar getBar() {}</div><div style="font-family:arial,sans-serif;font-size:13px">}</div><div style="font-family:arial,sans-serif;font-size:13px">
<br></div><div style="font-family:arial,sans-serif;font-size:13px"><div>interface IFoo2 {</div><div> @Valid</div><div> public Bar getBar() {}</div><div>}</div></div><div style="font-family:arial,sans-serif;font-size:13px">
<br></div><div style="font-family:arial,sans-serif;font-size:13px"><div>class FooImpl implements IFoo1, IFoo2 {</div><div> @Override<br></div><div> public Bar getBar() {}</div><div>}</div><div><br></div><div>Is this legal? The wording in 4.5.5 seems a bit unclear:</div>
<div><br></div><div>> One must not mark a method return value
for cascaded validation more than once in a class hierarchy.</div><div><br></div><div>This would render the situation above illegal. But then it goes on:</div><div><br></div><div>> In
other words, sub types (be it sub classes/interfaces or interface
implementations) cannot mark the return value for cascaded
validation if the return value has already been marked on a super
type or interface.<br></div><div><br></div><div>This describes only the subtype situation, not addressing the situation above and thus implying that it is legal. Maybe we just remove the second sentence? I think it is also understandable on its own right due to the other cases before.</div>
<div><br></div><div>Note that constraint mappings are explicitly forbidden for parallel hierarchies in section 4.4.5.</div><div><br></div><div style>Emmanuel, what was our intention when forbidding to specify @Valid several times? Forbidding several occurrences of @ConvertGroup makes sense to me due to the LSP, but several @Valid don't seem problematic to me.</div>
<div style><br></div><div style>Or was it to "transitively" cover the @ConvertGroup case since we also say that @ConvertGroup may only be given where @Valid is specified?</div><div style><br></div><div style>I think it would make sense to either</div>
<div style><br></div><div style>* Forbid several occurrences of @Valid (subtypes, parallel hierarchies); Allow @ConvertGroup only where @Valid is given; Don't have additional rules for @ConvertGroup</div><div style><br>
</div><div style>OR</div><div style><br></div><div style>* Allow several occurrences of @Valid; Allow @ConvertGroup only where @Valid is given; Forbid several occurrences of @ConvertGroup (subtypes, parallel hierarchies)</div>
<div style><br></div><div style>WDYT?</div><div style><br></div><div style>--Gunnar</div>
<div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2013/1/28 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">Yes that was the idea to only offer the first variant as valid. If the spec is too unclear open an issue.<br>
<div><div><br>
On 28 janv. 2013, at 17:51, Gunnar Morling <<a href="mailto:gunnar@hibernate.org" target="_blank">gunnar@hibernate.org</a>> wrote:<br>
<br>
> Emmanuel, all,<br>
><br>
> I need a short confirmation related to the definition of group conversions for the return value of an overriding method. IIUC, the 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 @Valid itself is added in SubFoo only. It would be illegal if @Valid was given in Foo, too.<br>
><br>
> I think that makes sense since LSP is not violated by the first variant, while it would in the second (a user of Foo wouldn't be aware of the applying conversions).<br>
><br>
> Right?<br>
><br>
> Thanks,<br>
><br>
> --Gunnar<br>
><br>
</div></div>> _______________________________________________<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>
_______________________________________________<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>
</blockquote></div><br></div></div>