[bv-dev] Value extraction open issue #2: per constraint ConstraintsApplyTo?
Matt Benson
mbenson at apache.org
Fri Jan 13 12:54:50 EST 2017
On Fri, Jan 13, 2017 at 10:55 AM, Gunnar Morling <gunnar at 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 at apache.org>:
> >
> >
> > On Fri, Jan 13, 2017 at 10:23 AM, Matt Benson <mbenson at apache.org>
> wrote:
> >>
> >>
> >> On Fri, Jan 13, 2017 at 8:57 AM, Emmanuel Bernard <
> emmanuel at hibernate.org>
> >> wrote:
> >>>
> >>> s/other/order from the JVM/
> >>>
> >>> > On 13 Jan 2017, at 15:54, Emmanuel Bernard <emmanuel at 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 at 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 at hibernate.org
> >:
> >>> >>>
> >>> >>> On 13 Jan 2017, at 13:29, Guillaume Smet <guillaume.smet at gmail.com
> >
> >>> >>> wrote:
> >>> >>>
> >>> >>> On Fri, Jan 13, 2017 at 1:01 PM, Gunnar Morling
> >>> >>> <gunnar at 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 at lists.jboss.org
> >>> >>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >>> >>
> >>> >> _______________________________________________
> >>> >> beanvalidation-dev mailing list
> >>> >> beanvalidation-dev at lists.jboss.org
> >>> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >>> >
> >>> >
> >>> > _______________________________________________
> >>> > beanvalidation-dev mailing list
> >>> > beanvalidation-dev at lists.jboss.org
> >>> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >>>
> >>>
> >>> _______________________________________________
> >>> beanvalidation-dev mailing list
> >>> beanvalidation-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >>
> >>
> >
> >
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170113/e018785a/attachment-0001.html
More information about the beanvalidation-dev
mailing list