9:41 a.m.
Hi everyone,
I hope you had some time to experiment with the functionality in Hibernate Validator
5.0.0.Alpha1.
One question Gunnar and I discussed when implementing the latest spec was constructor
validation and constraints on super types.
Probably best to use an example:
public class Foo {
Foo(@Length(max = 10) String s) {
}
Foo(@Min(5) Integer i) {
}
public void foobar(@NotNull String s) {
// ...
}
}
public class Bar extends Foo {
public Bar(String s) {
super( s );
}
public void foobar(String s) {
// ...
}
}
In this case we have Bar extending Foo. What happens if Bar#foobar is called? In this case
the @NotNull constraint from
Foo#foobar get applied. So far so good. The question is what happens with constructor
validation?
In the example Bar has one constructor which defines no constraint. The matching super
type constructor Foo(String) defines
an @Length constraint. Should this constraint be applied? In the example Bar(String) calls
the corresponding string constructor
in the super type, but it might as well call the integer constructor. There is no telling
from a Bean Validation point of view.
For this reason Hibernate Validator does not apply any super types constraints when
validating constructors. We think that is
the right behavior, but wanted to run this by everyone. Either way it is probably worth to
clarify the spec around this.
Thoughts?
--Hardy
11:11 a.m.
There is method overriding, but no constructor overriding. Therefore,
it seems perfectly fine for me.
Regards,
Michael
On Sat, Jun 30, 2012 at 4:41 AM, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
Hi everyone,
I hope you had some time to experiment with the functionality in Hibernate Validator
5.0.0.Alpha1.
One question Gunnar and I discussed when implementing the latest spec was constructor
validation and constraints on super types.
Probably best to use an example:
public class Foo {
Foo(@Length(max = 10) String s) {
}
Foo(@Min(5) Integer i) {
}
public void foobar(@NotNull String s) {
// ...
}
}
public class Bar extends Foo {
public Bar(String s) {
super( s );
}
public void foobar(String s) {
// ...
}
}
In this case we have Bar extending Foo. What happens if Bar#foobar is called? In this
case the @NotNull constraint from
Foo#foobar get applied. So far so good. The question is what happens with constructor
validation?
In the example Bar has one constructor which defines no constraint. The matching super
type constructor Foo(String) defines
an @Length constraint. Should this constraint be applied? In the example Bar(String)
calls the corresponding string constructor
in the super type, but it might as well call the integer constructor. There is no telling
from a Bean Validation point of view.
For this reason Hibernate Validator does not apply any super types constraints when
validating constructors. We think that is
the right behavior, but wanted to run this by everyone. Either way it is probably worth
to clarify the spec around this.
Thoughts?
--Hardy
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
11:31 a.m.
I agree with Michael and you. We would only come up with fairly arbitrary and unintuitive
rules. Depending on the interception technology we even might end up with double
validations.
On 30 juin 2012, at 11:11, Michael Nascimento wrote:
There is method overriding, but no constructor overriding.
Therefore,
it seems perfectly fine for me.
Regards,
Michael
On Sat, Jun 30, 2012 at 4:41 AM, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
> Hi everyone,
>
> I hope you had some time to experiment with the functionality in Hibernate Validator
5.0.0.Alpha1.
> One question Gunnar and I discussed when implementing the latest spec was constructor
validation and constraints on super types.
>
> Probably best to use an example:
>
>
> public class Foo {
> Foo(@Length(max = 10) String s) {
> }
>
> Foo(@Min(5) Integer i) {
> }
>
> public void foobar(@NotNull String s) {
> // ...
> }
> }
>
> public class Bar extends Foo {
> public Bar(String s) {
> super( s );
> }
>
> public void foobar(String s) {
> // ...
> }
> }
>
> In this case we have Bar extending Foo. What happens if Bar#foobar is called? In this
case the @NotNull constraint from
> Foo#foobar get applied. So far so good. The question is what happens with constructor
validation?
>
> In the example Bar has one constructor which defines no constraint. The matching
super type constructor Foo(String) defines
> an @Length constraint. Should this constraint be applied? In the example Bar(String)
calls the corresponding string constructor
> in the super type, but it might as well call the integer constructor. There is no
telling from a Bean Validation point of view.
>
> For this reason Hibernate Validator does not apply any super types constraints when
validating constructors. We think that is
> the right behavior, but wanted to run this by everyone. Either way it is probably
worth to clarify the spec around this.
>
> Thoughts?
>
> --Hardy
> _______________________________________________
> 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
4:05 p.m.
Cool. I created BVAL-300. I think we just have to write a couple of clarifying sentences
in the spec.
--Hardy
On Jul 1, 2012, at 11:31 AM, Emmanuel Bernard wrote:
I agree with Michael and you. We would only come up with fairly
arbitrary and unintuitive rules. Depending on the interception technology we even might
end up with double validations.
On 30 juin 2012, at 11:11, Michael Nascimento wrote:
> There is method overriding, but no constructor overriding. Therefore,
> it seems perfectly fine for me.
4309
days inactive
4311
days old
beanvalidation-dev@lists.jboss.org
3 comments
3 participants
participants (3)
-
Emmanuel Bernard -
Hardy Ferentschik -
Michael Nascimento