Answers inline.

2013/1/30 Emmanuel Bernard <emmanuel@hibernate.org>
The discussion was thankfully captured in BVAL-332

> 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:
> @Valid can only be defined at the top level for params as per the existing rules
> @Valid can be defined on return values
> 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.
> 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.
> If we find a better solution over the week end we can change that

To me defined in the same class hierarchy means a direct line between a
method and an overridden method because we are precisely talking about
methods and not the whole class. But two methods with the same sig in
parallel interfaces implemented by a class does not seem to fall into
this category.

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.
 

    interface Baz1 {
        @Valid
        public Var getBar();
    }

    class Baz2 {
        @Valid
        public Var getBar();
    }

    class Baz3 extends Baz2 implements Baz1 {
    }

I do think this is a valid usage of @Valid but would be dangerous if
compound with @ConvertGroup. That's why there is this special provision
in 4.4.5

> Likewise, if a sub type overrides/implements a method originally
> defined in several parallel types of the hierarchy [...] and if that
> method's return value has been marked for cascading validation in one
> of the parallel types, no group conversion rule may be declared for
> that method's return value in the parallel types of the hierarchy.
 
So what about your example, clearly it falls into that rule and this
@ConvertGroup is not allowed but is it legal to @Override parallel
methods marked with @Valid. I'm tempted to say yes. Thoughts?

Yes, that makes sense given the above definition of "class hierarchy".

But the crux is that I'm not sure we can call these two parallel methods
to be a single one and thus be defined several times in the class
hierarchy even if it is overridden later in by Foo3.

Anything I should change in the spec to make that clearer?

I think it would help to explicitly mention that several "parallel" return value @Valid annotations are legal in the rule in 4.5.5 ("One must not mark a method return value for cascaded validation more than once in a class hierarchy...").

A related question is what the implications of these rules are for the specification of @Valid on properties (getter methods).

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.


Emmanuel

Thanks,

--Gunnar
 

On Tue 2013-01-29  9:24, Gunnar Morling wrote:
> 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
> >

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