FYI, I've created https://hibernate.onjira.com/browse/BVAL-365 to clarify the related wording.


2013/1/29 Gunnar Morling <gunnar@hibernate.org>
Ok, thanks. How is it with specifying @Valid on parallel types:

interface IFoo1 {
    @Valid
    public Bar getBar() {}
}

interface IFoo2 {
    @Valid
    public Bar getBar() {}
}

class FooImpl implements IFoo1, IFoo2 {
    @Override
    public Bar getBar() {}
}

Is this legal? The wording in 4.5.5 seems a bit unclear:

> One must not mark a method return value for cascaded validation more than once in a class hierarchy.

This would render the situation above illegal. But then it goes on:

> 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.

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.

Note that constraint mappings are explicitly forbidden for parallel hierarchies in section 4.4.5.

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.

Or was it to "transitively" cover the @ConvertGroup case since we also say that @ConvertGroup may only be given where @Valid is specified?

I think it would make sense to either

* Forbid several occurrences of @Valid (subtypes, parallel hierarchies); Allow @ConvertGroup only where @Valid is given; Don't have additional rules for @ConvertGroup

OR

* Allow several occurrences of @Valid; Allow @ConvertGroup only where @Valid is given; Forbid several occurrences of @ConvertGroup (subtypes, parallel hierarchies)

WDYT?

--Gunnar


2013/1/28 Emmanuel Bernard <emmanuel@hibernate.org>
Yes that was the idea to only offer the first variant as valid. If the spec is too unclear open an issue.

On 28 janv. 2013, at 17:51, Gunnar Morling <gunnar@hibernate.org> wrote:

> Emmanuel, all,
>
> 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:
>
> Class Foo {
>     public Bar getBar() {}
> }
>
> Class SubFoo extends Foo {
>
>     @Valid
>     @ConvertGroup(from=..., to=...)
>     @Override
>     public Bar getBar() {}
> }
>
> 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.
>
> 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).
>
> Right?
>
> Thanks,
>
> --Gunnar
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev