[bv-dev] Group conversion on overridden method

[Emmanuel Bernard]

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.

    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?

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?

Emmanuel

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 at 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 at 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 at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >

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