2:33 a.m.
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(a)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(a)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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev