4:21 p.m.
Hi all,
As per the latest spec draft, a constraint must be either a cross-parameter
*or* a generic constraint, but not both at the same time, as otherwise it
would be ambiguous whether a constraint on a method refers to the method
parameters or return value.
Most of the time this does not really pose a limitation, but some
constraints actually might be both, cross-parameter *and* generic,
depending on the specific context. Examples are @ScriptAssert in Hibernate
Validator or generic constraints such as this:
@EqualPasswords
public void register(String userName, String password, String
confirmedPassword) {
}
@EqualPasswords
public class ResetPasswordRequest {
String userName;
String password;
String confirmedPassword;
}
Based on a recent BVAL issue [1], I'm proposing to introduce a special
constraint annotation attribute, "validationAppliesTo", allowing to specify
the required behavior at the usage site:
@EqualPasswords(validationAppliesTo=PARAMETERS)
public void register(String username, String password, String
confirmPassword) {
}
@EqualPasswords(validationAppliesTo=ANNOTATED_ELEMENT)
public class ResetPasswordRequest {
String password;
String confirmedPassword;
}
The following rules would apply:
* If a constraint is annotated with @Constraint and
@CrossParameterConstraint, it must define a member "validationAppliesTo".
The default value should be ANNOTATED_ELEMENT.
* If a constraint is annotated with only one
of @Constraint/@CrossParameterConstraint, defining a "validationAppliesTo"
member doesn't have any special effect
* Specifying validationAppliesTo=PARAMETERS anywhere except a method causes
ConstraintDeclarationException
Any thoughts?
--Gunnar
[1] https://hibernate.onjira.com/browse/BVAL-340
9:22 a.m.
Anyone with thoughts/feedback on this?
Thanks,
--Gunnar
2013/1/7 Gunnar Morling <gunnar(a)hibernate.org>
Hi all,
As per the latest spec draft, a constraint must be either a
cross-parameter *or* a generic constraint, but not both at the same
time, as otherwise it would be ambiguous whether a constraint on a method
refers to the method parameters or return value.
Most of the time this does not really pose a limitation, but some
constraints actually might be both, cross-parameter *and* generic,
depending on the specific context. Examples are @ScriptAssert in Hibernate
Validator or generic constraints such as this:
@EqualPasswords
public void register(String userName, String password, String
confirmedPassword) {
}
@EqualPasswords
public class ResetPasswordRequest {
String userName;
String password;
String confirmedPassword;
}
Based on a recent BVAL issue [1], I'm proposing to introduce a special
constraint annotation attribute, "validationAppliesTo", allowing to specify
the required behavior at the usage site:
@EqualPasswords(validationAppliesTo=PARAMETERS)
public void register(String username, String password, String
confirmPassword) {
}
@EqualPasswords(validationAppliesTo=ANNOTATED_ELEMENT)
public class ResetPasswordRequest {
String password;
String confirmedPassword;
}
The following rules would apply:
* If a constraint is annotated with @Constraint and
@CrossParameterConstraint, it must define a member "validationAppliesTo".
The default value should be ANNOTATED_ELEMENT.
* If a constraint is annotated with only one
of @Constraint/@CrossParameterConstraint, defining a "validationAppliesTo"
member doesn't have any special effect
* Specifying validationAppliesTo=PARAMETERS anywhere except a method
causes ConstraintDeclarationException
Any thoughts?
--Gunnar
[1] https://hibernate.onjira.com/browse/BVAL-340
9:47 a.m.
Hi Gunnar,
I kind of like the idea of being able to use a single constraint
definition type for either purpose, in that it avoids forcing users through
semantic obstacles in expressing some basic concept. I'm less enthralled
with another "magic" annotation element name, but I don't have a better
idea at the moment either. I'm disagree with the idea that the default
'validationAppliesTo' value should be ANNOTATED_ELEMENT; I personally would
rather see a default such as IMPLICIT whose presence requires that only one
of @Constraint or @CrossParameterConstraint be present on the annotation
type.
Matt
On Fri, Jan 11, 2013 at 9:22 AM, Gunnar Morling <gunnar(a)hibernate.org>wrote:
Anyone with thoughts/feedback on this?
Thanks,
--Gunnar
2013/1/7 Gunnar Morling <gunnar(a)hibernate.org>
> Hi all,
>
> As per the latest spec draft, a constraint must be either a
> cross-parameter *or* a generic constraint, but not both at the same
> time, as otherwise it would be ambiguous whether a constraint on a method
> refers to the method parameters or return value.
>
> Most of the time this does not really pose a limitation, but some
> constraints actually might be both, cross-parameter *and* generic,
> depending on the specific context. Examples are @ScriptAssert in Hibernate
> Validator or generic constraints such as this:
>
> @EqualPasswords
> public void register(String userName, String password, String
> confirmedPassword) {
> }
>
> @EqualPasswords
> public class ResetPasswordRequest {
> String userName;
> String password;
> String confirmedPassword;
> }
>
> Based on a recent BVAL issue [1], I'm proposing to introduce a special
> constraint annotation attribute, "validationAppliesTo", allowing to
specify
> the required behavior at the usage site:
>
> @EqualPasswords(validationAppliesTo=PARAMETERS)
> public void register(String username, String password, String
> confirmPassword) {
> }
>
> @EqualPasswords(validationAppliesTo=ANNOTATED_ELEMENT)
> public class ResetPasswordRequest {
> String password;
> String confirmedPassword;
> }
>
> The following rules would apply:
>
> * If a constraint is annotated with @Constraint and
> @CrossParameterConstraint, it must define a member "validationAppliesTo".
> The default value should be ANNOTATED_ELEMENT.
> * If a constraint is annotated with only one
> of @Constraint/@CrossParameterConstraint, defining a "validationAppliesTo"
> member doesn't have any special effect
> * Specifying validationAppliesTo=PARAMETERS anywhere except a method
> causes ConstraintDeclarationException
>
> Any thoughts?
>
> --Gunnar
>
> [1] https://hibernate.onjira.com/browse/BVAL-340
>
>
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
9:48 a.m.
On Fri, Jan 11, 2013 at 9:47 AM, Matt Benson <mbenson(a)apache.org> wrote:
Hi Gunnar,
I kind of like the idea of being able to use a single constraint
definition type for either purpose, in that it avoids forcing users through
semantic obstacles in expressing some basic concept. I'm less enthralled
with another "magic" annotation element name, but I don't have a better
idea at the moment either. I'm disagree with the idea that the default
'validationAppliesTo' value should be
s/I'm disagree/I disagree/ :P
ANNOTATED_ELEMENT; I personally would rather see a default such as
IMPLICIT whose presence requires that only one of @Constraint or
@CrossParameterConstraint be present on the annotation type.
Matt
On Fri, Jan 11, 2013 at 9:22 AM, Gunnar Morling <gunnar(a)hibernate.org>wrote:
> Anyone with thoughts/feedback on this?
>
> Thanks,
>
> --Gunnar
>
>
> 2013/1/7 Gunnar Morling <gunnar(a)hibernate.org>
>
>> Hi all,
>>
>> As per the latest spec draft, a constraint must be either a
>> cross-parameter *or* a generic constraint, but not both at the same
>> time, as otherwise it would be ambiguous whether a constraint on a method
>> refers to the method parameters or return value.
>>
>> Most of the time this does not really pose a limitation, but some
>> constraints actually might be both, cross-parameter *and* generic,
>> depending on the specific context. Examples are @ScriptAssert in Hibernate
>> Validator or generic constraints such as this:
>>
>> @EqualPasswords
>> public void register(String userName, String password, String
>> confirmedPassword) {
>> }
>>
>> @EqualPasswords
>> public class ResetPasswordRequest {
>> String userName;
>> String password;
>> String confirmedPassword;
>> }
>>
>> Based on a recent BVAL issue [1], I'm proposing to introduce a special
>> constraint annotation attribute, "validationAppliesTo", allowing to
specify
>> the required behavior at the usage site:
>>
>> @EqualPasswords(validationAppliesTo=PARAMETERS)
>> public void register(String username, String password, String
>> confirmPassword) {
>> }
>>
>> @EqualPasswords(validationAppliesTo=ANNOTATED_ELEMENT)
>> public class ResetPasswordRequest {
>> String password;
>> String confirmedPassword;
>> }
>>
>> The following rules would apply:
>>
>> * If a constraint is annotated with @Constraint and
>> @CrossParameterConstraint, it must define a member
"validationAppliesTo".
>> The default value should be ANNOTATED_ELEMENT.
>> * If a constraint is annotated with only one
>> of @Constraint/@CrossParameterConstraint, defining a
"validationAppliesTo"
>> member doesn't have any special effect
>> * Specifying validationAppliesTo=PARAMETERS anywhere except a method
>> causes ConstraintDeclarationException
>>
>> Any thoughts?
>>
>> --Gunnar
>>
>> [1] https://hibernate.onjira.com/browse/BVAL-340
>>
>>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
3:56 a.m.
Hi Matt,
2013/1/11 Matt Benson <mbenson(a)apache.org>
I'm less enthralled with another "magic" annotation
element name, but I
don't have a better idea at the moment either.
Yes, it's too bad one can't define interfaces for annotations. Constraint
correctness can still be checked at compile time using an annotation
processor or similar, but as you say these annotation member names are
somewhat implicit.
--Gunnar
7:52 a.m.
After letting this idea rest for a while, I still like it.
In the issue, you also proposed to go a step further and get rid of
@CrossParameterConstraint altogether. I sort of remember not being keen
on the idea to protect future evolutions on the type-safe
cross-parameter way. Have you thought about it more? What is your
opinion?
Emmanuel
On Mon 2013-01-07 23:21, Gunnar Morling wrote:
Hi all,
As per the latest spec draft, a constraint must be either a cross-parameter
*or* a generic constraint, but not both at the same time, as otherwise it
would be ambiguous whether a constraint on a method refers to the method
parameters or return value.
Most of the time this does not really pose a limitation, but some
constraints actually might be both, cross-parameter *and* generic,
depending on the specific context. Examples are @ScriptAssert in Hibernate
Validator or generic constraints such as this:
@EqualPasswords
public void register(String userName, String password, String
confirmedPassword) {
}
@EqualPasswords
public class ResetPasswordRequest {
String userName;
String password;
String confirmedPassword;
}
Based on a recent BVAL issue [1], I'm proposing to introduce a special
constraint annotation attribute, "validationAppliesTo", allowing to specify
the required behavior at the usage site:
@EqualPasswords(validationAppliesTo=PARAMETERS)
public void register(String username, String password, String
confirmPassword) {
}
@EqualPasswords(validationAppliesTo=ANNOTATED_ELEMENT)
public class ResetPasswordRequest {
String password;
String confirmedPassword;
}
The following rules would apply:
* If a constraint is annotated with @Constraint and
@CrossParameterConstraint, it must define a member "validationAppliesTo".
The default value should be ANNOTATED_ELEMENT.
* If a constraint is annotated with only one
of @Constraint/@CrossParameterConstraint, defining a "validationAppliesTo"
member doesn't have any special effect
* Specifying validationAppliesTo=PARAMETERS anywhere except a method causes
ConstraintDeclarationException
Any thoughts?
--Gunnar
[1] https://hibernate.onjira.com/browse/BVAL-340
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
3:53 a.m.
2013/1/14 Emmanuel Bernard <emmanuel(a)hibernate.org>
After letting this idea rest for a while, I still like it.
In the issue, you also proposed to go a step further and get rid of
@CrossParameterConstraint altogether. I sort of remember not being keen
on the idea to protect future evolutions on the type-safe
cross-parameter way. Have you thought about it more? What is your
opinion?
Yes, I still like the idea of having only the @Constraint annotation for
defining constraints, but one problem I see is that one can not specify
different validators for return value arrays and method argument arrays in
cases like this:
@MyCustomConstraint(validationAppliesTo = PARAMETERS)
public void foo(int p1, int p2) { ... }
@MyCustomConstraint(validationAppliesTo = ANNOTATED_ELEMENT)
public Object[] bar() { ... }
With the different annotations @Constraint and @CrossParameterConstraint,
two different validators (both parameterized with <MyCustomConstraint,
Object[]>) could be specified here. Not sure, how relevant this is in
reality, though.
An alternative would be to extend @Constraint to accommodate the
specification of generic validator(s) and/or a cross-parameter validator:
public @interface Constraint {
Class<? extends ConstraintValidator<?, ?>>[] validatedBy() default
{};
Class<? extends ConstraintValidator<?, ?>>
crossParameterValidatorType() default ConstraintValidator.class;
}
The same rules would apply, i.e. the constraint must have a
"validationAppliesTo" attribute in case validators for both cases are
specified.
Thinking about Matt's IMPLICIT suggestion a bit more, I guess we could even
limit the cases where the constraint user must actually set the
"validationAppliesTo" attribute to those cases where it can't be inferred
automatically:
//"validationAppliesTo" not required, since method is void
@MyCustomConstraint
public void foo(int p1, int p2) { ... }
//not required, since method has no parameters
@MyCustomConstraint
public Object[] bar() { ... }
//"validationAppliesTo" required if constraint has a (generic)
validator for Baz and cross-param validator for Object[]
@MyCustomConstraint(validationAppliesTo = ANNOTATED_ELEMENT)
public Baz foo(int p1, int p2) { ... }
//"validationAppliesTo" required if constraint has a (generic)
validator for Object[] and cross-param validator for Object[]
@MyCustomConstraint(validationAppliesTo = PARAMETERS)
public Object[] foo(int p1, int p2) { ... }
The ValidationTarget enum would have the values IMPLICIT (default),
ANNOTATED_ELEMENT and PARAMETERS.
WDYT?
--Gunnar
Emmanuel
On Mon 2013-01-07 23:21, Gunnar Morling wrote:
> Hi all,
>
> As per the latest spec draft, a constraint must be either a
cross-parameter
> *or* a generic constraint, but not both at the same time, as otherwise it
> would be ambiguous whether a constraint on a method refers to the method
> parameters or return value.
>
> Most of the time this does not really pose a limitation, but some
> constraints actually might be both, cross-parameter *and* generic,
> depending on the specific context. Examples are @ScriptAssert in
Hibernate
> Validator or generic constraints such as this:
>
> @EqualPasswords
> public void register(String userName, String password, String
> confirmedPassword) {
> }
>
> @EqualPasswords
> public class ResetPasswordRequest {
> String userName;
> String password;
> String confirmedPassword;
> }
>
> Based on a recent BVAL issue [1], I'm proposing to introduce a special
> constraint annotation attribute, "validationAppliesTo", allowing to
specify
> the required behavior at the usage site:
>
> @EqualPasswords(validationAppliesTo=PARAMETERS)
> public void register(String username, String password, String
> confirmPassword) {
> }
>
> @EqualPasswords(validationAppliesTo=ANNOTATED_ELEMENT)
> public class ResetPasswordRequest {
> String password;
> String confirmedPassword;
> }
>
> The following rules would apply:
>
> * If a constraint is annotated with @Constraint and
> @CrossParameterConstraint, it must define a member "validationAppliesTo".
> The default value should be ANNOTATED_ELEMENT.
> * If a constraint is annotated with only one
> of @Constraint/@CrossParameterConstraint, defining a
"validationAppliesTo"
> member doesn't have any special effect
> * Specifying validationAppliesTo=PARAMETERS anywhere except a method
causes
> ConstraintDeclarationException
>
> Any thoughts?
>
> --Gunnar
>
> [1] https://hibernate.onjira.com/browse/BVAL-340
> _______________________________________________
> 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:57 a.m.
Hi,
I think with the additional IMPLICIT option the cases where the user actually needs to
specify 'validationAppliesTo' is really minimised.
+1 for this option
--Hardy
On 15 Jan 2013, at 10:53 AM, Gunnar Morling <gunnar(a)hibernate.org> wrote:
2013/1/14 Emmanuel Bernard <emmanuel(a)hibernate.org>
After letting this idea rest for a while, I still like it.
In the issue, you also proposed to go a step further and get rid of
@CrossParameterConstraint altogether. I sort of remember not being keen
on the idea to protect future evolutions on the type-safe
cross-parameter way. Have you thought about it more? What is your
opinion?
Yes, I still like the idea of having only the @Constraint annotation for defining
constraints, but one problem I see is that one can not specify different validators for
return value arrays and method argument arrays in cases like this:
@MyCustomConstraint(validationAppliesTo = PARAMETERS)
public void foo(int p1, int p2) { ... }
@MyCustomConstraint(validationAppliesTo = ANNOTATED_ELEMENT)
public Object[] bar() { ... }
With the different annotations @Constraint and @CrossParameterConstraint, two different
validators (both parameterized with <MyCustomConstraint, Object[]>) could be
specified here. Not sure, how relevant this is in reality, though.
An alternative would be to extend @Constraint to accommodate the specification of generic
validator(s) and/or a cross-parameter validator:
public @interface Constraint {
Class<? extends ConstraintValidator<?, ?>>[] validatedBy() default
{};
Class<? extends ConstraintValidator<?, ?>>
crossParameterValidatorType() default ConstraintValidator.class;
}
The same rules would apply, i.e. the constraint must have a
"validationAppliesTo" attribute in case validators for both cases are
specified.
Thinking about Matt's IMPLICIT suggestion a bit more, I guess we could even limit the
cases where the constraint user must actually set the "validationAppliesTo"
attribute to those cases where it can't be inferred automatically:
//"validationAppliesTo" not required, since method is void
@MyCustomConstraint
public void foo(int p1, int p2) { ... }
//not required, since method has no parameters
@MyCustomConstraint
public Object[] bar() { ... }
//"validationAppliesTo" required if constraint has a (generic) validator
for Baz and cross-param validator for Object[]
@MyCustomConstraint(validationAppliesTo = ANNOTATED_ELEMENT)
public Baz foo(int p1, int p2) { ... }
//"validationAppliesTo" required if constraint has a (generic) validator
for Object[] and cross-param validator for Object[]
@MyCustomConstraint(validationAppliesTo = PARAMETERS)
public Object[] foo(int p1, int p2) { ... }
The ValidationTarget enum would have the values IMPLICIT (default), ANNOTATED_ELEMENT and
PARAMETERS.
WDYT?
--Gunnar
Emmanuel
On Mon 2013-01-07 23:21, Gunnar Morling wrote:
> Hi all,
>
> As per the latest spec draft, a constraint must be either a cross-parameter
> *or* a generic constraint, but not both at the same time, as otherwise it
> would be ambiguous whether a constraint on a method refers to the method
> parameters or return value.
>
> Most of the time this does not really pose a limitation, but some
> constraints actually might be both, cross-parameter *and* generic,
> depending on the specific context. Examples are @ScriptAssert in Hibernate
> Validator or generic constraints such as this:
>
> @EqualPasswords
> public void register(String userName, String password, String
> confirmedPassword) {
> }
>
> @EqualPasswords
> public class ResetPasswordRequest {
> String userName;
> String password;
> String confirmedPassword;
> }
>
> Based on a recent BVAL issue [1], I'm proposing to introduce a special
> constraint annotation attribute, "validationAppliesTo", allowing to
specify
> the required behavior at the usage site:
>
> @EqualPasswords(validationAppliesTo=PARAMETERS)
> public void register(String username, String password, String
> confirmPassword) {
> }
>
> @EqualPasswords(validationAppliesTo=ANNOTATED_ELEMENT)
> public class ResetPasswordRequest {
> String password;
> String confirmedPassword;
> }
>
> The following rules would apply:
>
> * If a constraint is annotated with @Constraint and
> @CrossParameterConstraint, it must define a member "validationAppliesTo".
> The default value should be ANNOTATED_ELEMENT.
> * If a constraint is annotated with only one
> of @Constraint/@CrossParameterConstraint, defining a
"validationAppliesTo"
> member doesn't have any special effect
> * Specifying validationAppliesTo=PARAMETERS anywhere except a method causes
> ConstraintDeclarationException
>
> Any thoughts?
>
> --Gunnar
>
> [1] https://hibernate.onjira.com/browse/BVAL-340
> _______________________________________________
> 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
7:45 a.m.
I can live with that but we must make it crystal clear that in case of
ambiguity, we raise an exception. Otherwise, someone changing the method
sig might have some nasty surprises.
Emmanuel
On Tue 2013-01-15 11:57, Hardy Ferentschik wrote:
Hi,
I think with the additional IMPLICIT option the cases where the user actually needs to
specify 'validationAppliesTo' is really minimised.
+1 for this option
--Hardy
On 15 Jan 2013, at 10:53 AM, Gunnar Morling <gunnar(a)hibernate.org> wrote:
> 2013/1/14 Emmanuel Bernard <emmanuel(a)hibernate.org>
> After letting this idea rest for a while, I still like it.
>
> In the issue, you also proposed to go a step further and get rid of
> @CrossParameterConstraint altogether. I sort of remember not being keen
> on the idea to protect future evolutions on the type-safe
> cross-parameter way. Have you thought about it more? What is your
> opinion?
>
> Yes, I still like the idea of having only the @Constraint annotation for defining
constraints, but one problem I see is that one can not specify different validators for
return value arrays and method argument arrays in cases like this:
>
> @MyCustomConstraint(validationAppliesTo = PARAMETERS)
> public void foo(int p1, int p2) { ... }
>
> @MyCustomConstraint(validationAppliesTo = ANNOTATED_ELEMENT)
> public Object[] bar() { ... }
>
> With the different annotations @Constraint and @CrossParameterConstraint, two
different validators (both parameterized with <MyCustomConstraint, Object[]>) could
be specified here. Not sure, how relevant this is in reality, though.
>
> An alternative would be to extend @Constraint to accommodate the specification of
generic validator(s) and/or a cross-parameter validator:
>
> public @interface Constraint {
> Class<? extends ConstraintValidator<?, ?>>[] validatedBy()
default {};
> Class<? extends ConstraintValidator<?, ?>>
crossParameterValidatorType() default ConstraintValidator.class;
> }
>
> The same rules would apply, i.e. the constraint must have a
"validationAppliesTo" attribute in case validators for both cases are
specified.
>
> Thinking about Matt's IMPLICIT suggestion a bit more, I guess we could even
limit the cases where the constraint user must actually set the
"validationAppliesTo" attribute to those cases where it can't be inferred
automatically:
>
> //"validationAppliesTo" not required, since method is void
> @MyCustomConstraint
> public void foo(int p1, int p2) { ... }
>
> //not required, since method has no parameters
> @MyCustomConstraint
> public Object[] bar() { ... }
>
> //"validationAppliesTo" required if constraint has a (generic)
validator for Baz and cross-param validator for Object[]
> @MyCustomConstraint(validationAppliesTo = ANNOTATED_ELEMENT)
> public Baz foo(int p1, int p2) { ... }
>
> //"validationAppliesTo" required if constraint has a (generic)
validator for Object[] and cross-param validator for Object[]
> @MyCustomConstraint(validationAppliesTo = PARAMETERS)
> public Object[] foo(int p1, int p2) { ... }
>
> The ValidationTarget enum would have the values IMPLICIT (default),
ANNOTATED_ELEMENT and PARAMETERS.
>
> WDYT?
>
> --Gunnar
>
>
>
> Emmanuel
>
> On Mon 2013-01-07 23:21, Gunnar Morling wrote:
> > Hi all,
> >
> > As per the latest spec draft, a constraint must be either a cross-parameter
> > *or* a generic constraint, but not both at the same time, as otherwise it
> > would be ambiguous whether a constraint on a method refers to the method
> > parameters or return value.
> >
> > Most of the time this does not really pose a limitation, but some
> > constraints actually might be both, cross-parameter *and* generic,
> > depending on the specific context. Examples are @ScriptAssert in Hibernate
> > Validator or generic constraints such as this:
> >
> > @EqualPasswords
> > public void register(String userName, String password, String
> > confirmedPassword) {
> > }
> >
> > @EqualPasswords
> > public class ResetPasswordRequest {
> > String userName;
> > String password;
> > String confirmedPassword;
> > }
> >
> > Based on a recent BVAL issue [1], I'm proposing to introduce a special
> > constraint annotation attribute, "validationAppliesTo", allowing to
specify
> > the required behavior at the usage site:
> >
> > @EqualPasswords(validationAppliesTo=PARAMETERS)
> > public void register(String username, String password, String
> > confirmPassword) {
> > }
> >
> > @EqualPasswords(validationAppliesTo=ANNOTATED_ELEMENT)
> > public class ResetPasswordRequest {
> > String password;
> > String confirmedPassword;
> > }
> >
> > The following rules would apply:
> >
> > * If a constraint is annotated with @Constraint and
> > @CrossParameterConstraint, it must define a member
"validationAppliesTo".
> > The default value should be ANNOTATED_ELEMENT.
> > * If a constraint is annotated with only one
> > of @Constraint/@CrossParameterConstraint, defining a
"validationAppliesTo"
> > member doesn't have any special effect
> > * Specifying validationAppliesTo=PARAMETERS anywhere except a method causes
> > ConstraintDeclarationException
> >
> > Any thoughts?
> >
> > --Gunnar
> >
> > [1] https://hibernate.onjira.com/browse/BVAL-340
>
> > _______________________________________________
> > 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
8:14 a.m.
2013/1/15 Emmanuel Bernard <emmanuel(a)hibernate.org>
I can live with that but we must make it crystal clear that in case
of
ambiguity, we raise an exception. Otherwise, someone changing the method
sig might have some nasty surprises.
And which of the options
@CrossParameterConstraint(validatedBy=MyCrossParameterValidator.class)
@Constraint(validatedBy=MyGenericValidator.class)
public @interface MyConstraint { ... }
vs.
@Constraint(
validatedBy=MyGenericValidator.class,
crossParameterValidatorType=MyCrossParameterValidator.class
)
public @interface MyConstraint { ... }
would you prefer?
Personally I'd lean towards the latter, since there would be exactly one
meta-annotation denoting an annotation as constraint annotation type, with
all attributes for the required configuration.
If following the 2nd approach, we should IMO add a default clause to
validatedBy() (set to the empty array), allowing for
the convenient definition of cross-parameter only constraints. According to
[1] this change would be binary-compatible.
But this is no strong preference, I could also live with the two separate
annotations.
--Gunnar
[1]
http://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_interface...
3:19 a.m.
I must admit I have not made my mind. The small advantage I find in having two annotations
is that it is readable at a glance what the constraint is even just by reading its javadoc
(assuming @Documented). In the second approach, you need to explicitly put it in the
javadoc or have your users access to the source code and parse the @Constraint
What do others think?
On 15 janv. 2013, at 15:14, Gunnar Morling <gunnar(a)hibernate.org> wrote:
2013/1/15 Emmanuel Bernard <emmanuel(a)hibernate.org>
> I can live with that but we must make it crystal clear that in case of
> ambiguity, we raise an exception. Otherwise, someone changing the method
> sig might have some nasty surprises.
And which of the options
@CrossParameterConstraint(validatedBy=MyCrossParameterValidator.class)
@Constraint(validatedBy=MyGenericValidator.class)
public @interface MyConstraint { ... }
vs.
@Constraint(
validatedBy=MyGenericValidator.class,
crossParameterValidatorType=MyCrossParameterValidator.class
)
public @interface MyConstraint { ... }
would you prefer?
Personally I'd lean towards the latter, since there would be exactly one
meta-annotation denoting an annotation as constraint annotation type, with all attributes
for the required configuration.
If following the 2nd approach, we should IMO add a default clause to validatedBy() (set
to the empty array), allowing for the convenient definition of cross-parameter only
constraints. According to [1] this change would be binary-compatible.
But this is no strong preference, I could also live with the two separate annotations.
--Gunnar
[1]
http://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_interface...
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
3:30 a.m.
I find two annotations also more intuitive and easier to read/understand.
+1 for explicit @CrossParameterConstraint + @Constraint
--Hardy
On 16 Jan 2013, at 10:19 AM, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
I must admit I have not made my mind. The small advantage I find in
having two annotations is that it is readable at a glance what the constraint is even just
by reading its javadoc (assuming @Documented). In the second approach, you need to
explicitly put it in the javadoc or have your users access to the source code and parse
the @Constraint
What do others think?
On 15 janv. 2013, at 15:14, Gunnar Morling <gunnar(a)hibernate.org> wrote:
> 2013/1/15 Emmanuel Bernard <emmanuel(a)hibernate.org>
> I can live with that but we must make it crystal clear that in case of
> ambiguity, we raise an exception. Otherwise, someone changing the method
> sig might have some nasty surprises.
>
> And which of the options
>
> @CrossParameterConstraint(validatedBy=MyCrossParameterValidator.class)
> @Constraint(validatedBy=MyGenericValidator.class)
> public @interface MyConstraint { ... }
>
> vs.
>
> @Constraint(
> validatedBy=MyGenericValidator.class,
> crossParameterValidatorType=MyCrossParameterValidator.class
> )
> public @interface MyConstraint { ... }
>
> would you prefer?
>
> Personally I'd lean towards the latter, since there would be exactly one
meta-annotation denoting an annotation as constraint annotation type, with all attributes
for the required configuration.
>
> If following the 2nd approach, we should IMO add a default clause to validatedBy()
(set to the empty array), allowing for the convenient definition of cross-parameter only
constraints. According to [1] this change would be binary-compatible.
>
> But this is no strong preference, I could also live with the two separate
annotations.
>
> --Gunnar
>
> [1]
http://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_interface...
> _______________________________________________
> 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
5:39 a.m.
2013/1/16 Emmanuel Bernard <emmanuel(a)hibernate.org>
The small advantage I find in having two annotations is that it is
readable at a glance what the constraint is even just by reading its
javadoc (assuming @Documented). In the second approach, you need to
explicitly put it in the javadoc or have your users access to the source
code and parse the @Constraint
Which JavaDoc do you mean, the JavaDoc for the definition a constraint
annotation type or the JavaDoc for an element annotated with a constraint
annotation?
The former contains all meta annotations, including their members, so the
type would be recognizable either way. The latter only contains the actual
constraint annotation itself (i.e. no meta-annotations) if the constraint
is annotated with @Documented. So afaics, from the JavaDoc of a constraint
usage site it's not recognizable whether the constraint is generic or
cross-parameter (if it's not encoded into the name).
Or did you mean something else?
--Gunnar
8:52 a.m.
Yes I meant the former. I did not know the attribute values are also
shown on the JavaDoc of an annotated element.
On Wed 2013-01-16 12:39, Gunnar Morling wrote:
2013/1/16 Emmanuel Bernard <emmanuel(a)hibernate.org>
> The small advantage I find in having two annotations is that it is
> readable at a glance what the constraint is even just by reading its
> javadoc (assuming @Documented). In the second approach, you need to
> explicitly put it in the javadoc or have your users access to the source
> code and parse the @Constraint
Which JavaDoc do you mean, the JavaDoc for the definition a constraint
annotation type or the JavaDoc for an element annotated with a constraint
annotation?
The former contains all meta annotations, including their members, so the
type would be recognizable either way. The latter only contains the actual
constraint annotation itself (i.e. no meta-annotations) if the constraint
is annotated with @Documented. So afaics, from the JavaDoc of a constraint
usage site it's not recognizable whether the constraint is generic or
cross-parameter (if it's not encoded into the name).
Or did you mean something else?
--Gunnar
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
11:35 a.m.
On the subject, Gunnar and I were discussing three valid options to
define a constraint as cross-parameter constraint:
## @CrossParametersConstraint
(first off I hate the name, can't we find a better one?)
@Constraint(validatedBy=ObjectScriptAssert.class)
@CrossParametersConstraint(validatedBy=ObjectScriptAssert.class)
public @interface ScriptAssert { ... }
## @Constraint for both
@Constraint(validatedBy=ObjectScriptAssert.class
validatedByForCrossParameters=ObjectScriptAssert.class)
public @interface ScriptAssert { ... }
## @Validates on ConstraintValidator
@Constraint(validatedBy=ObjectScriptAssert.class)
public @interface ScriptAssert { ... }
@Validates({CROSS_PARAMETERS, ANNOTATED_ELEMENTS})
public class ObjectScriptAssert implements
ConstraintValidator<ScriptAssert,Object[]> { ... }
## Thoughts
I think I like @CrossParametersConstraints more than @Constraint for
both as it makes things explicit and keep the simple use case as is.
But I am intrigued by the @Validates option. In many ways, it's similar
to how we resolve the right constraint validator based on the type. The
only difference is that the @Validates annotation refines how Object[]
should be interpreted. It "fits better" in my opinion.
My concern around the latest option is that it forces us to be a
subclass of ConstraintViolation for the foreseeable future including
when we reopen the type-safe options we explored in
http://beanvalidation.org/proposals/BVAL-232/
Thoughts and comments?
Emmanuel
On Tue 2013-01-15 15:14, Gunnar Morling wrote:
2013/1/15 Emmanuel Bernard <emmanuel(a)hibernate.org>
> I can live with that but we must make it crystal clear that in case of
> ambiguity, we raise an exception. Otherwise, someone changing the method
> sig might have some nasty surprises.
>
And which of the options
@CrossParameterConstraint(validatedBy=MyCrossParameterValidator.class)
@Constraint(validatedBy=MyGenericValidator.class)
public @interface MyConstraint { ... }
vs.
@Constraint(
validatedBy=MyGenericValidator.class,
crossParameterValidatorType=MyCrossParameterValidator.class
)
public @interface MyConstraint { ... }
would you prefer?
Personally I'd lean towards the latter, since there would be exactly one
meta-annotation denoting an annotation as constraint annotation type, with
all attributes for the required configuration.
If following the 2nd approach, we should IMO add a default clause to
validatedBy() (set to the empty array), allowing for
the convenient definition of cross-parameter only constraints. According to
[1] this change would be binary-compatible.
But this is no strong preference, I could also live with the two separate
annotations.
--Gunnar
[1]
http://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_interface...
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
11:52 a.m.
On Mon, Jan 21, 2013 at 11:35 AM, Emmanuel Bernard
<emmanuel(a)hibernate.org>wrote:
On the subject, Gunnar and I were discussing three valid options to
define a constraint as cross-parameter constraint:
## @CrossParametersConstraint
(first off I hate the name, can't we find a better one?)
@Constraint(validatedBy=ObjectScriptAssert.class)
@CrossParametersConstraint(validatedBy=ObjectScriptAssert.class)
public @interface ScriptAssert { ... }
## @Constraint for both
@Constraint(validatedBy=ObjectScriptAssert.class
validatedByForCrossParameters=ObjectScriptAssert.class)
public @interface ScriptAssert { ... }
## @Validates on ConstraintValidator
@Constraint(validatedBy=ObjectScriptAssert.class)
public @interface ScriptAssert { ... }
@Validates({CROSS_PARAMETERS, ANNOTATED_ELEMENTS})
public class ObjectScriptAssert implements
ConstraintValidator<ScriptAssert,Object[]> { ... }
## Thoughts
I think I like @CrossParametersConstraints more than @Constraint for
both as it makes things explicit and keep the simple use case as is.
But I am intrigued by the @Validates option. In many ways, it's similar
to how we resolve the right constraint validator based on the type. The
only difference is that the @Validates annotation refines how Object[]
should be interpreted. It "fits better" in my opinion.
My concern around the latest option is that it forces us to be a
subclass of ConstraintViolation for the foreseeable future including
when we reopen the type-safe options we explored in
http://beanvalidation.org/proposals/BVAL-232/
Thoughts and comments?
So you're saying @Validates would eliminate the need for a separate
CrossParameterConstraintValidator interface? FWIW, it seems to me that the
separate interface just feels more straightforward.
Matt
Emmanuel
On Tue 2013-01-15 15:14, Gunnar Morling wrote:
> 2013/1/15 Emmanuel Bernard <emmanuel(a)hibernate.org>
>
> > I can live with that but we must make it crystal clear that in case of
> > ambiguity, we raise an exception. Otherwise, someone changing the
method
> > sig might have some nasty surprises.
> >
>
> And which of the options
>
>
@CrossParameterConstraint(validatedBy=MyCrossParameterValidator.class)
> @Constraint(validatedBy=MyGenericValidator.class)
> public @interface MyConstraint { ... }
>
> vs.
>
> @Constraint(
> validatedBy=MyGenericValidator.class,
> crossParameterValidatorType=MyCrossParameterValidator.class
> )
> public @interface MyConstraint { ... }
>
> would you prefer?
>
> Personally I'd lean towards the latter, since there would be exactly one
> meta-annotation denoting an annotation as constraint annotation type,
with
> all attributes for the required configuration.
>
> If following the 2nd approach, we should IMO add a default clause to
> validatedBy() (set to the empty array), allowing for
> the convenient definition of cross-parameter only constraints. According
to
> [1] this change would be binary-compatible.
>
> But this is no strong preference, I could also live with the two separate
> annotations.
>
> --Gunnar
>
> [1]
>
http://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_interface...
> _______________________________________________
> 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
12:06 p.m.
On Mon 2013-01-21 11:52, Matt Benson wrote:
> ## Thoughts
>
> I think I like @CrossParametersConstraints more than @Constraint for
> both as it makes things explicit and keep the simple use case as is.
>
> But I am intrigued by the @Validates option. In many ways, it's similar
> to how we resolve the right constraint validator based on the type. The
> only difference is that the @Validates annotation refines how Object[]
> should be interpreted. It "fits better" in my opinion.
>
> My concern around the latest option is that it forces us to be a
> subclass of ConstraintViolation for the foreseeable future including
> when we reopen the type-safe options we explored in
> http://beanvalidation.org/proposals/BVAL-232/
>
> Thoughts and comments?
>
>
So you're saying @Validates would eliminate the need for a separate
CrossParameterConstraintValidator interface? FWIW, it seems to me that the
separate interface just feels more straightforward.
It would eliminate the need for a separate @CrossParametersConstraint
annotation. There is no CrossParameterConstraintValidator interface
in the current proposals. We explored that briefly with Gunnar today too
but this approach cannot cover all cases.
Emmanuel
4:52 a.m.
On 21 Jan 2013, at 6:35 PM, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
I think I like @CrossParametersConstraints more than @Constraint for
both as it makes things explicit and keep the simple use case as is.
+1 I like an explicit @CrossParametersConstraints also better than attributes on
@Constraint.
But I am intrigued by the @Validates option. In many ways, it's
similar
to how we resolve the right constraint validator based on the type. The
only difference is that the @Validates annotation refines how Object[]
should be interpreted. It "fits better" in my opinion.
I could live with this option as well.
My concern around the latest option is that it forces us to be a
subclass of ConstraintViolation for the foreseeable future including
you mean ConstraintValidator, right? I don't mind being tied to that,
especially since I never been a big fan of some of the type-safe approaches.
--Hardy
5:05 a.m.
2013/1/21 Emmanuel Bernard <emmanuel(a)hibernate.org>
My concern around the latest option is that it forces us to be a
subclass of ConstraintViolation for the foreseeable future including
when we reopen the type-safe options we explored in
http://beanvalidation.org/proposals/BVAL-232/
If we want to include a type-safe approach later on, we might do it like
this:
* Pull ConstraintValidator#initialize() up into a new interface
Initializeable
* Change @CrossParameterConstraint#validatedBy() to return Class<?
extendsInitializable<?, ?>>. AFAICS that shouldn't be a problem for
existing
constraint definitions, BV providers need of course to adapt. Short tests I
did looked good.
--Gunnar
4112
days inactive
4127
days old
beanvalidation-dev@lists.jboss.org
18 comments
4 participants
participants (4)
-
Emmanuel Bernard -
Gunnar Morling -
Hardy Ferentschik -
Matt Benson