4:50 a.m.
Hi,
This is the first of a series of threads about the open questions regarding
value extraction [1]. We hope having a separate thread per question will
help having a more structured and easy to follow discussion.
Summary of the issue
================
ConstraintsApplyTo only allows one behavior per annotated element. Should
it be per constraint? E.g. for @NotNull @Email StringProperty email it may
be desirable to apply @NotNull to the wrapper but @Email to the wrapped
value. That’s not possible currently.
Summary of the discussions going on
============================
Matt proposed something like:
@ConstraintsApplyTo(target=WRAPPED_VALUE, constraintTypes=Size.class)
@Size(3)
List<String> nicknames;
As noted by Emmanuel, it does not solve the issue when you want 2 @Size
constraints, one for the List and the other for the enclosed String.
Emmanuel proposed to use groups to solve this issue:
"
But it makes me think that we sorta addresssed a similar class of problem
with groups.
I haven’t explored at all but could we something similar by subverting
groups. Let’s define two special groups: OnContainer OnWrappedValue
@Min(value3, groups=OnWrappedValue.class)
List<String> nicknames;
"
[1] http://beanvalidation.org/latest-draft/spec/#_open_questions
5:12 a.m.
Hi,
I don't think relying on groups is such a good idea. It's already a
complicated area and adding some magic groups won't help.
Is there something preventing us from doing something like:
@Size(3, applyTo = ANNOTATED_ELEMENT)
@Size(10, applyTo = WRAPPED_VALUE)
ListOfStrings nicknames;
ANNOTATED_ELEMENT would be the default and would mean apply the constraint
to the currently annotated element.
So List<@Size(10) String> would mean apply the constraint to the annotated
element so to the String.
List<@Size(10, applyTo = WRAPPED_VALUE) Optional<String>> would apply the
constraint to the String contained in the Optional.
The drawback I can see is that it adds a new reserved method to the
@Constraint annotations. To make the migration more smooth, we could make
it optional and test the returnType of the method before using the result.
--
Guillaume
5:22 a.m.
Hi again,
On Fri, Jan 13, 2017 at 12:12 PM, Guillaume Smet <guillaume.smet(a)gmail.com>
wrote:
The drawback I can see is that it adds a new reserved method to the
@Constraint annotations. To make the migration more smooth, we could make
it optional and test the returnType of the method before using the result.
After speaking with Gunnar, we would need a "valid" prefix on the name of
the method so something like validationAppliesTo would work:
@Size(3, validationAppliesTo = ANNOTATED_ELEMENT)
@Size(10, validationAppliesTo = WRAPPED_VALUE)
ListOfStrings nicknames;
--
Guillaume
6:01 a.m.
Unfortunately, validationAppliesTo() is already taken:
http://beanvalidation.org/latest-draft/spec/#constraintsdefinitionimpleme...
It's used to distinguish between return value and cross-parameter constraints.
Any other name I can think of right now would make up for much
confusion with that option.
2017-01-13 12:22 GMT+01:00 Guillaume Smet <guillaume.smet(a)gmail.com>:
Hi again,
On Fri, Jan 13, 2017 at 12:12 PM, Guillaume Smet <guillaume.smet(a)gmail.com>
wrote:
>
> The drawback I can see is that it adds a new reserved method to the
> @Constraint annotations. To make the migration more smooth, we could make it
> optional and test the returnType of the method before using the result.
After speaking with Gunnar, we would need a "valid" prefix on the name of
the method so something like validationAppliesTo would work:
@Size(3, validationAppliesTo = ANNOTATED_ELEMENT)
@Size(10, validationAppliesTo = WRAPPED_VALUE)
ListOfStrings nicknames;
--
Guillaume
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
6:29 a.m.
On Fri, Jan 13, 2017 at 1:01 PM, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
Unfortunately, validationAppliesTo() is already taken:
http://beanvalidation.org/latest-draft/spec/#
constraintsdefinitionimplementation-constraintdefinition-
validationappliesto
It's used to distinguish between return value and cross-parameter
constraints.
Any other name I can think of right now would make up for much
confusion with that option.
Too good to be true :).
That being said, I'm wondering if we could reuse it and just add 2 other
values to ConstraintTarget. All in all, it's the same concept. The default
being IMPLICIT is not too bad either.
--
Guillaume
7:58 a.m.
On 13 Jan 2017, at 13:29, Guillaume Smet
<guillaume.smet(a)gmail.com> wrote:
On Fri, Jan 13, 2017 at 1:01 PM, Gunnar Morling <gunnar(a)hibernate.org
<mailto:gunnar@hibernate.org>> wrote:
Unfortunately, validationAppliesTo() is already taken:
http://beanvalidation.org/latest-draft/spec/#constraintsdefinitionimpleme...
<http://beanvalidation.org/latest-draft/spec/#constraintsdefinitionimpleme...
It's used to distinguish between return value and cross-parameter constraints.
Any other name I can think of right now would make up for much
confusion with that option.
Too good to be true :).
That being said, I'm wondering if we could reuse it and just add 2 other values to
ConstraintTarget. All in all, it's the same concept. The default being IMPLICIT is not
too bad either.
Right I think it’s worth exploring.
I still like my group repurposing trick though even if it offenses the clean camp :)
8:22 a.m.
As a variation of Matt's idea, an optional index() parameter could be added:
@Size(1)
@Size(3)
@ApplyConstraintTo(constraint=Size.class, index=1, target=WRAPPED_VALUE)
List<String> nicknames;
It could be omitted (via a default value of -1 or similar) if there is
only one constraint of the type in question:
@NotNull
@Email
@ApplyConstraintTo(constraint=NotNull.class, target=ANNOTATED_ELEMENT)
Optional<String> email;
Does the trick, though it's still a tad verbose.
2017-01-13 14:58 GMT+01:00 Emmanuel Bernard <emmanuel(a)hibernate.org>:
On 13 Jan 2017, at 13:29, Guillaume Smet <guillaume.smet(a)gmail.com> wrote:
On Fri, Jan 13, 2017 at 1:01 PM, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
>
> Unfortunately, validationAppliesTo() is already taken:
>
>
http://beanvalidation.org/latest-draft/spec/#constraintsdefinitionimpleme...
>
> It's used to distinguish between return value and cross-parameter
> constraints.
>
> Any other name I can think of right now would make up for much
> confusion with that option.
Too good to be true :).
That being said, I'm wondering if we could reuse it and just add 2 other
values to ConstraintTarget. All in all, it's the same concept. The default
being IMPLICIT is not too bad either.
Right I think it’s worth exploring.
I still like my group repurposing trick though even if it offenses the clean
camp :)
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
8:54 a.m.
I looked at that, and I’m not sure you are guaranteed to get an other.
Plus you have this problem
@Min
@Min.List({@Min, @Min})
@Min
BooYahh foo;
On 13 Jan 2017, at 15:22, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
As a variation of Matt's idea, an optional index() parameter could be added:
@Size(1)
@Size(3)
@ApplyConstraintTo(constraint=Size.class, index=1, target=WRAPPED_VALUE)
List<String> nicknames;
It could be omitted (via a default value of -1 or similar) if there is
only one constraint of the type in question:
@NotNull
@Email
@ApplyConstraintTo(constraint=NotNull.class, target=ANNOTATED_ELEMENT)
Optional<String> email;
Does the trick, though it's still a tad verbose.
2017-01-13 14:58 GMT+01:00 Emmanuel Bernard <emmanuel(a)hibernate.org>:
>
> On 13 Jan 2017, at 13:29, Guillaume Smet <guillaume.smet(a)gmail.com> wrote:
>
> On Fri, Jan 13, 2017 at 1:01 PM, Gunnar Morling <gunnar(a)hibernate.org>
> wrote:
>>
>> Unfortunately, validationAppliesTo() is already taken:
>>
>>
http://beanvalidation.org/latest-draft/spec/#constraintsdefinitionimpleme...
>>
>> It's used to distinguish between return value and cross-parameter
>> constraints.
>>
>> Any other name I can think of right now would make up for much
>> confusion with that option.
>
>
> Too good to be true :).
>
> That being said, I'm wondering if we could reuse it and just add 2 other
> values to ConstraintTarget. All in all, it's the same concept. The default
> being IMPLICIT is not too bad either.
>
>
> Right I think it’s worth exploring.
> I still like my group repurposing trick though even if it offenses the clean
> camp :)
>
> _______________________________________________
> 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:57 a.m.
s/other/order from the JVM/
On 13 Jan 2017, at 15:54, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
I looked at that, and I’m not sure you are guaranteed to get an other.
Plus you have this problem
@Min
@Min.List({@Min, @Min})
@Min
BooYahh foo;
> On 13 Jan 2017, at 15:22, Gunnar Morling <gunnar(a)hibernate.org> wrote:
>
> As a variation of Matt's idea, an optional index() parameter could be added:
>
> @Size(1)
> @Size(3)
> @ApplyConstraintTo(constraint=Size.class, index=1, target=WRAPPED_VALUE)
> List<String> nicknames;
>
> It could be omitted (via a default value of -1 or similar) if there is
> only one constraint of the type in question:
>
> @NotNull
> @Email
> @ApplyConstraintTo(constraint=NotNull.class, target=ANNOTATED_ELEMENT)
> Optional<String> email;
>
> Does the trick, though it's still a tad verbose.
>
>
> 2017-01-13 14:58 GMT+01:00 Emmanuel Bernard <emmanuel(a)hibernate.org>:
>>
>> On 13 Jan 2017, at 13:29, Guillaume Smet <guillaume.smet(a)gmail.com> wrote:
>>
>> On Fri, Jan 13, 2017 at 1:01 PM, Gunnar Morling <gunnar(a)hibernate.org>
>> wrote:
>>>
>>> Unfortunately, validationAppliesTo() is already taken:
>>>
>>>
http://beanvalidation.org/latest-draft/spec/#constraintsdefinitionimpleme...
>>>
>>> It's used to distinguish between return value and cross-parameter
>>> constraints.
>>>
>>> Any other name I can think of right now would make up for much
>>> confusion with that option.
>>
>>
>> Too good to be true :).
>>
>> That being said, I'm wondering if we could reuse it and just add 2 other
>> values to ConstraintTarget. All in all, it's the same concept. The default
>> being IMPLICIT is not too bad either.
>>
>>
>> Right I think it’s worth exploring.
>> I still like my group repurposing trick though even if it offenses the clean
>> camp :)
>>
>> _______________________________________________
>> 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
10:23 a.m.
On Fri, Jan 13, 2017 at 8:57 AM, Emmanuel Bernard <emmanuel(a)hibernate.org>
wrote:
s/other/order from the JVM/
> On 13 Jan 2017, at 15:54, Emmanuel Bernard <emmanuel(a)hibernate.org>
wrote:
>
> I looked at that, and I’m not sure you are guaranteed to get an other.
> Plus you have this problem
>
> @Min
> @Min.List({@Min, @Min})
> @Min
> BooYahh foo;
>
I would have thought the same; however per [1] order is guaranteed. Your
additional concern is still there. Maybe it would be cleaner to support
this using meta-constraint annotations.
>> On 13 Jan 2017, at 15:22, Gunnar Morling
<gunnar(a)hibernate.org> wrote:
>>
>> As a variation of Matt's idea, an optional index() parameter could be
added:
>>
>> @Size(1)
>> @Size(3)
>> @ApplyConstraintTo(constraint=Size.class, index=1,
target=WRAPPED_VALUE)
>> List<String> nicknames;
>>
>> It could be omitted (via a default value of -1 or similar) if there is
>> only one constraint of the type in question:
>>
>> @NotNull
>> @Email
>> @ApplyConstraintTo(constraint=NotNull.class,
target=ANNOTATED_ELEMENT)
>> Optional<String> email;
>>
>> Does the trick, though it's still a tad verbose.
>>
>>
>> 2017-01-13 14:58 GMT+01:00 Emmanuel Bernard <emmanuel(a)hibernate.org>:
>>>
>>> On 13 Jan 2017, at 13:29, Guillaume Smet <guillaume.smet(a)gmail.com>
wrote:
>>>
>>> On Fri, Jan 13, 2017 at 1:01 PM, Gunnar Morling
<gunnar(a)hibernate.org>
>>> wrote:
>>>>
>>>> Unfortunately, validationAppliesTo() is already taken:
>>>>
>>>> http://beanvalidation.org/latest-draft/spec/#
constraintsdefinitionimplementation-constraintdefinition-
validationappliesto
>>>>
>>>> It's used to distinguish between return value and cross-parameter
>>>> constraints.
>>>>
>>>> Any other name I can think of right now would make up for much
>>>> confusion with that option.
>>>
>>>
>>> Too good to be true :).
>>>
>>> That being said, I'm wondering if we could reuse it and just add 2
other
>>> values to ConstraintTarget. All in all, it's the same concept. The
default
>>> being IMPLICIT is not too bad either.
>>>
>>>
>>> Right I think it’s worth exploring.
>>> I still like my group repurposing trick though even if it offenses the
clean
>>> camp :)
>>>
I still can't figure out how you would use the group trick in conjunction
with validation of a "real" group.
Matt
[1] http://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.7.5
>>> _______________________________________________
>>> 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
10:39 a.m.
On Fri, Jan 13, 2017 at 10:23 AM, Matt Benson <mbenson(a)apache.org> wrote:
On Fri, Jan 13, 2017 at 8:57 AM, Emmanuel Bernard <emmanuel(a)hibernate.org>
wrote:
> s/other/order from the JVM/
>
> > On 13 Jan 2017, at 15:54, Emmanuel Bernard <emmanuel(a)hibernate.org>
> wrote:
> >
> > I looked at that, and I’m not sure you are guaranteed to get an other.
> > Plus you have this problem
> >
> > @Min
> > @Min.List({@Min, @Min})
> > @Min
> > BooYahh foo;
> >
>
I would have thought the same; however per [1] order is guaranteed. Your
additional concern is still there. Maybe it would be cleaner to support
this using meta-constraint annotations.
Actually, per the same section of the JLS, your example is referred to as
"obtuse" (which I'm sure was the point you were making) would generate a
compile error. So we could perhaps support Gunnar's approach after all. A
meta-annotation might look cleaner, but it might become painful to define a
lot of these.
Matt
> >> On 13 Jan 2017, at 15:22, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
> >>
> >> As a variation of Matt's idea, an optional index() parameter could be
> added:
> >>
> >> @Size(1)
> >> @Size(3)
> >> @ApplyConstraintTo(constraint=Size.class, index=1,
> target=WRAPPED_VALUE)
> >> List<String> nicknames;
> >>
> >> It could be omitted (via a default value of -1 or similar) if there is
> >> only one constraint of the type in question:
> >>
> >> @NotNull
> >> @Email
> >> @ApplyConstraintTo(constraint=NotNull.class,
> target=ANNOTATED_ELEMENT)
> >> Optional<String> email;
> >>
> >> Does the trick, though it's still a tad verbose.
> >>
> >>
> >> 2017-01-13 14:58 GMT+01:00 Emmanuel Bernard <emmanuel(a)hibernate.org>:
> >>>
> >>> On 13 Jan 2017, at 13:29, Guillaume Smet
<guillaume.smet(a)gmail.com>
> wrote:
> >>>
> >>> On Fri, Jan 13, 2017 at 1:01 PM, Gunnar Morling
<gunnar(a)hibernate.org
> >
> >>> wrote:
> >>>>
> >>>> Unfortunately, validationAppliesTo() is already taken:
> >>>>
> >>>> http://beanvalidation.org/latest-draft/spec/#constraintsdefi
> nitionimplementation-constraintdefinition-validationappliesto
> >>>>
> >>>> It's used to distinguish between return value and
cross-parameter
> >>>> constraints.
> >>>>
> >>>> Any other name I can think of right now would make up for much
> >>>> confusion with that option.
> >>>
> >>>
> >>> Too good to be true :).
> >>>
> >>> That being said, I'm wondering if we could reuse it and just add 2
> other
> >>> values to ConstraintTarget. All in all, it's the same concept. The
> default
> >>> being IMPLICIT is not too bad either.
> >>>
> >>>
> >>> Right I think it’s worth exploring.
> >>> I still like my group repurposing trick though even if it offenses
> the clean
> >>> camp :)
> >>>
>
I still can't figure out how you would use the group trick in conjunction
with validation of a "real" group.
Matt
[1] http://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.7.5
> >>> _______________________________________________
> >>> 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
>
10:55 a.m.
Right, Emmanuel's example isn't legal:
"It is a compile-time error if, in a declaration context or type
context, there are multiple annotations of a repeatable annotation
type T and any annotations of the containing annotation type of T."
But it's also says that given a single instance of the repeatable
annotation type and the container annotation is valid:
@Min
@Min.List({@Min})
BooYahh foo;
I'm not sure how the ordering is defined - and if so, how. If we could
confirm that this case can be resolved deterministically, too, then it
should be doable.
A meta-annotation might look cleaner, but it might become painful to
define a lot of these.
What exactly do you mean here? Can you give an example?
2017-01-13 17:39 GMT+01:00 Matt Benson <mbenson(a)apache.org>:
On Fri, Jan 13, 2017 at 10:23 AM, Matt Benson <mbenson(a)apache.org> wrote:
>
>
> On Fri, Jan 13, 2017 at 8:57 AM, Emmanuel Bernard <emmanuel(a)hibernate.org>
> wrote:
>>
>> s/other/order from the JVM/
>>
>> > On 13 Jan 2017, at 15:54, Emmanuel Bernard <emmanuel(a)hibernate.org>
>> > wrote:
>> >
>> > I looked at that, and I’m not sure you are guaranteed to get an other.
>> > Plus you have this problem
>> >
>> > @Min
>> > @Min.List({@Min, @Min})
>> > @Min
>> > BooYahh foo;
>> >
>
>
> I would have thought the same; however per [1] order is guaranteed. Your
> additional concern is still there. Maybe it would be cleaner to support this
> using meta-constraint annotations.
Actually, per the same section of the JLS, your example is referred to as
"obtuse" (which I'm sure was the point you were making) would generate a
compile error. So we could perhaps support Gunnar's approach after all. A
meta-annotation might look cleaner, but it might become painful to define a
lot of these.
Matt
>
>
>>
>> >> On 13 Jan 2017, at 15:22, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
>> >>
>> >> As a variation of Matt's idea, an optional index() parameter could
be
>> >> added:
>> >>
>> >> @Size(1)
>> >> @Size(3)
>> >> @ApplyConstraintTo(constraint=Size.class, index=1,
>> >> target=WRAPPED_VALUE)
>> >> List<String> nicknames;
>> >>
>> >> It could be omitted (via a default value of -1 or similar) if there is
>> >> only one constraint of the type in question:
>> >>
>> >> @NotNull
>> >> @Email
>> >> @ApplyConstraintTo(constraint=NotNull.class,
>> >> target=ANNOTATED_ELEMENT)
>> >> Optional<String> email;
>> >>
>> >> Does the trick, though it's still a tad verbose.
>> >>
>> >>
>> >> 2017-01-13 14:58 GMT+01:00 Emmanuel Bernard
<emmanuel(a)hibernate.org>:
>> >>>
>> >>> On 13 Jan 2017, at 13:29, Guillaume Smet
<guillaume.smet(a)gmail.com>
>> >>> wrote:
>> >>>
>> >>> On Fri, Jan 13, 2017 at 1:01 PM, Gunnar Morling
>> >>> <gunnar(a)hibernate.org>
>> >>> wrote:
>> >>>>
>> >>>> Unfortunately, validationAppliesTo() is already taken:
>> >>>>
>> >>>>
>> >>>>
http://beanvalidation.org/latest-draft/spec/#constraintsdefinitionimpleme...
>> >>>>
>> >>>> It's used to distinguish between return value and
cross-parameter
>> >>>> constraints.
>> >>>>
>> >>>> Any other name I can think of right now would make up for much
>> >>>> confusion with that option.
>> >>>
>> >>>
>> >>> Too good to be true :).
>> >>>
>> >>> That being said, I'm wondering if we could reuse it and just add
2
>> >>> other
>> >>> values to ConstraintTarget. All in all, it's the same concept.
The
>> >>> default
>> >>> being IMPLICIT is not too bad either.
>> >>>
>> >>>
>> >>> Right I think it’s worth exploring.
>> >>> I still like my group repurposing trick though even if it offenses
>> >>> the clean
>> >>> camp :)
>> >>>
>
>
> I still can't figure out how you would use the group trick in conjunction
> with validation of a "real" group.
>
> Matt
>
> [1] http://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.7.5
>
>>
>> >>> _______________________________________________
>> >>> 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
>
>
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
11:54 a.m.
On Fri, Jan 13, 2017 at 10:55 AM, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
Right, Emmanuel's example isn't legal:
"It is a compile-time error if, in a declaration context or type
context, there are multiple annotations of a repeatable annotation
type T and any annotations of the containing annotation type of T."
But it's also says that given a single instance of the repeatable
annotation type and the container annotation is valid:
@Min
@Min.List({@Min})
BooYahh foo;
I'm not sure how the ordering is defined - and if so, how. If we could
confirm that this case can be resolved deterministically, too, then it
should be doable.
Oh, right. :) Yeah, it would probably be natural to assume that the
resulting Min.List would contain all Min annotations in the order in which
they were encountered, but any assumption could also be dangerous.
> A meta-annotation might look cleaner, but it might become painful to
define a lot of these.
What exactly do you mean here? Can you give an example?
I'm thinking of an extension to the composed constraint feature. So:
@Size(min=3)
@ConstraintsApplyTo(WRAPPED_VALUE)
@Constraint
public @interface Nickname {
String message() default "";
Class<?> groups() default {};
Class<? extends Payload>[] payload() default {};
}
@Size(min=1) @Nickname List<String> nicknames;
The example is necessarily contrived where we're talking about a "normal"
typed extraction container, but should be applicable to:
@Size(min=1) @Nickname StringList nicknames;
As I warned, however, defining these might become tedious. It might be
helpful to define a mechanism (like that supported by Spring) to map
annotation elements:
@Size
@ConstraintsApplyTo(WRAPPED_VALUE)
@Constraint
public @interface WrappedSize {
@MapTo(type=Size.class, attribute="min")
int min() default 0;
@MapTo(type=Size.class, attribute="max")
int max() default Integer.MAX_VALUE;
String message() default "";
Class<?> groups() default {};
Class<? extends Payload>[] payload() default {};
}
@Size(1) @WrappedSize(min=3) StringList nicknames;
Matt
2017-01-13 17:39 GMT+01:00 Matt Benson <mbenson(a)apache.org>:
>
>
> On Fri, Jan 13, 2017 at 10:23 AM, Matt Benson <mbenson(a)apache.org>
wrote:
>>
>>
>> On Fri, Jan 13, 2017 at 8:57 AM, Emmanuel Bernard <
emmanuel(a)hibernate.org>
>> wrote:
>>>
>>> s/other/order from the JVM/
>>>
>>> > On 13 Jan 2017, at 15:54, Emmanuel Bernard
<emmanuel(a)hibernate.org>
>>> > wrote:
>>> >
>>> > I looked at that, and I’m not sure you are guaranteed to get an
other.
>>> > Plus you have this problem
>>> >
>>> > @Min
>>> > @Min.List({@Min, @Min})
>>> > @Min
>>> > BooYahh foo;
>>> >
>>
>>
>> I would have thought the same; however per [1] order is guaranteed. Your
>> additional concern is still there. Maybe it would be cleaner to support
this
>> using meta-constraint annotations.
>
>
> Actually, per the same section of the JLS, your example is referred to as
> "obtuse" (which I'm sure was the point you were making) would generate
a
> compile error. So we could perhaps support Gunnar's approach after all. A
> meta-annotation might look cleaner, but it might become painful to
define a
> lot of these.
>
> Matt
>>
>>
>>>
>>> >> On 13 Jan 2017, at 15:22, Gunnar Morling
<gunnar(a)hibernate.org>
wrote:
>>> >>
>>> >> As a variation of Matt's idea, an optional index() parameter
could
be
>>> >> added:
>>> >>
>>> >> @Size(1)
>>> >> @Size(3)
>>> >> @ApplyConstraintTo(constraint=Size.class, index=1,
>>> >> target=WRAPPED_VALUE)
>>> >> List<String> nicknames;
>>> >>
>>> >> It could be omitted (via a default value of -1 or similar) if
there
is
>>> >> only one constraint of the type in question:
>>> >>
>>> >> @NotNull
>>> >> @Email
>>> >> @ApplyConstraintTo(constraint=NotNull.class,
>>> >> target=ANNOTATED_ELEMENT)
>>> >> Optional<String> email;
>>> >>
>>> >> Does the trick, though it's still a tad verbose.
>>> >>
>>> >>
>>> >> 2017-01-13 14:58 GMT+01:00 Emmanuel Bernard
<emmanuel(a)hibernate.org
>:
>>> >>>
>>> >>> On 13 Jan 2017, at 13:29, Guillaume Smet
<guillaume.smet(a)gmail.com
>
>>> >>> wrote:
>>> >>>
>>> >>> On Fri, Jan 13, 2017 at 1:01 PM, Gunnar Morling
>>> >>> <gunnar(a)hibernate.org>
>>> >>> wrote:
>>> >>>>
>>> >>>> Unfortunately, validationAppliesTo() is already taken:
>>> >>>>
>>> >>>>
>>> >>>> http://beanvalidation.org/latest-draft/spec/#
constraintsdefinitionimplementation-constraintdefinition-
validationappliesto
>>> >>>>
>>> >>>> It's used to distinguish between return value and
cross-parameter
>>> >>>> constraints.
>>> >>>>
>>> >>>> Any other name I can think of right now would make up for
much
>>> >>>> confusion with that option.
>>> >>>
>>> >>>
>>> >>> Too good to be true :).
>>> >>>
>>> >>> That being said, I'm wondering if we could reuse it and
just add 2
>>> >>> other
>>> >>> values to ConstraintTarget. All in all, it's the same
concept. The
>>> >>> default
>>> >>> being IMPLICIT is not too bad either.
>>> >>>
>>> >>>
>>> >>> Right I think it’s worth exploring.
>>> >>> I still like my group repurposing trick though even if it
offenses
>>> >>> the clean
>>> >>> camp :)
>>> >>>
>>
>>
>> I still can't figure out how you would use the group trick in
conjunction
>> with validation of a "real" group.
>>
>> Matt
>>
>> [1] http://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#
jls-9.7.5
>>
>>>
>>> >>> _______________________________________________
>>> >>> 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
>>
>>
>
>
> _______________________________________________
> 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
6:56 a.m.
On 13 Jan 2017, at 18:54, Matt Benson <mbenson(a)apache.org>
wrote:
As I warned, however, defining these might become tedious. It might be helpful to define
a mechanism (like that supported by Spring) to map annotation elements:
@Size
@ConstraintsApplyTo(WRAPPED_VALUE)
@Constraint
public @interface WrappedSize {
@MapTo(type=Size.class, attribute="min")
int min() default 0;
@MapTo(type=Size.class, attribute="max")
int max() default Integer.MAX_VALUE;
String message() default "";
Class<?> groups() default {};
Class<? extends Payload>[] payload() default {};
}
@Size(1) @WrappedSize(min=3) StringList nicknames;
If you mean something like @MapTo, the spec already has that via @OverridesAttribute
AFAIK we invented it.
10:22 a.m.
On Tue, Jan 17, 2017 at 6:56 AM, Emmanuel Bernard <emmanuel(a)hibernate.org>
wrote:
On 13 Jan 2017, at 18:54, Matt Benson <mbenson(a)apache.org> wrote:
As I warned, however, defining these might become tedious. It might be
helpful to define a mechanism (like that supported by Spring) to map
annotation elements:
@Size
@ConstraintsApplyTo(WRAPPED_VALUE)
@Constraint
public @interface WrappedSize {
@MapTo(type=Size.class, attribute="min")
int min() default 0;
@MapTo(type=Size.class, attribute="max")
int max() default Integer.MAX_VALUE;
String message() default "";
Class<?> groups() default {};
Class<? extends Payload>[] payload() default {};
}
@Size(1) @WrappedSize(min=3) StringList nicknames;
If you mean something like @MapTo, the spec already has that via
@OverridesAttribute
AFAIK we invented it.
Sorry, it's been awhile since I've used BV in real life. But yes,
that's
what I mean.
Matt
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
8:19 a.m.
So I got confirmation from the JDK team that there is no guaranteed
order for retrieved annotations in the general case, causing any
index-based approach to fail.
The problem I see about the meta-annotation approach is that it
doesn't allow to re-use existing constraints without additional
changes, i.e. there's a migration hurdle for 3rd-party constraints
(similar to having a dedicated validationWrappedValue() member).
Now Emmanuel made the proposal to use the payload() feature for this:
@Size(1) Size(min=3, payload=Unwrapping.Unwrap.class) StringList nicknames;
While it feels a bit hack-ish, it puts the setting to the right level
(individual constraints as opposed to entire elements). So I think
it's a good basis, so we could move on with this for the time being
and hopefully get some exposure + feedback in an Alpha release.
--Gunnar
2017-01-17 17:22 GMT+01:00 Matt Benson <mbenson(a)apache.org>:
On Tue, Jan 17, 2017 at 6:56 AM, Emmanuel Bernard <emmanuel(a)hibernate.org>
wrote:
>
>
> On 13 Jan 2017, at 18:54, Matt Benson <mbenson(a)apache.org> wrote:
>
> As I warned, however, defining these might become tedious. It might be
> helpful to define a mechanism (like that supported by Spring) to map
> annotation elements:
>
> @Size
> @ConstraintsApplyTo(WRAPPED_VALUE)
> @Constraint
> public @interface WrappedSize {
>
> @MapTo(type=Size.class, attribute="min")
> int min() default 0;
>
> @MapTo(type=Size.class, attribute="max")
> int max() default Integer.MAX_VALUE;
>
> String message() default "";
> Class<?> groups() default {};
> Class<? extends Payload>[] payload() default {};
> }
>
> @Size(1) @WrappedSize(min=3) StringList nicknames;
>
>
> If you mean something like @MapTo, the spec already has that via
> @OverridesAttribute
> AFAIK we invented it.
>
Sorry, it's been awhile since I've used BV in real life. But yes, that's
what I mean.
Matt
>
> _______________________________________________
> 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
2669
days inactive
2674
days old
beanvalidation-dev@lists.jboss.org
15 comments
4 participants
participants (4)
-
Emmanuel Bernard -
Guillaume Smet -
Gunnar Morling -
Matt Benson