[bv-dev] Value extraction open issue #2: per constraint ConstraintsApplyTo?

[Gunnar Morling]

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 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