10:51 a.m.
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
11:12 a.m.
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
2:24 a.m.
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
2:35 a.m.
FYI, I've created https://hibernate.onjira.com/browse/BVAL-365 to clarify
the related wording.
2013/1/29 Gunnar Morling <gunnar(a)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(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
>
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
3:34 a.m.
Answers inline.
2013/1/30 Emmanuel Bernard <emmanuel(a)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(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
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
4348
days inactive
4350
days old
beanvalidation-dev@lists.jboss.org
5 comments
2 participants
participants (2)
-
Emmanuel Bernard -
Gunnar Morling