[bv-dev] Group conversion on overridden method
Gunnar Morling
gunnar at hibernate.org
Wed Jan 30 04:34:04 EST 2013
Answers inline.
2013/1/30 Emmanuel Bernard <emmanuel at 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 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
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20130130/f4a8a738/attachment.html
More information about the beanvalidation-dev
mailing list