[bv-dev] Value extraction - how to obtain the validated type for non-generic wrappers?

[Emmanuel Bernard]

It’s interesting.
How does that work when Ceylon decides to go for a native support instead of the extraction model? Can they keep a mix?
I.e. do we prioritize the actual ConstraintViolation<Min,ceylon.language.Integer> over a ValueExtractor<@ExtractedValue ceylon.language.Integer> + ConstraintViolation<Min,Integer>
I see that you used @UnwrapByDefault, my concern comes from that.

BTW it will mandate nested extractor support.

> On 23 Mar 2017, at 03:52, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
> Hi,
> 
> I've received some very interesting feedback on the value extraction
> proposal from our team working on the Ceylon language.
> 
> Ceylon does not only have its own collection framework, but also
> custom numeric wrappers, e.g. ceylon.language.Integer. Of course it'd
> be desirable to be able to apply existing constraints such as @Min to
> these. Instead of creating custom implementations such as
> ConstraintValidator<Min, ceylon.language.Integer> we thought value
> extractors could be used to enable all the existing constraints and
> validators:
> 
>    @UnwrapByDefault
>    public class IntegerValueExtractor implements
>                 ValueExtractor<@ExtractedValue ceylon.language.Integer> {
> 
>        public void extractValues(
>            ceylon.language.Integer originalValue, ValueReceiver receiver) {
> 
>            receiver.value( null, originalValue.getValue() );
>       }
>    }
> 
> The problem only is that BV cannot derive the wrapped type
> (java.lang.Integer) from the annotated extracted value type
> (ceylon.language.Integer) in this case, as it isn't generic.
> 
> My question is: should we support this use case? If so, how? One
> option I can see is allowing to specify the wrapped type explicitly if
> the wrapper is non-generic:
> 
>    public class IntegerValueExtractor implements
>        ValueExtractor<@ExtractedValue(type=int.class)
> ceylon.language.Integer> {
>        ...
>    }
> 
> type() would have a default value of void.class, so it doesn't have to
> be specified if the wrapped type can be derived.
> 
> We also could decide to not support, requiring integrators such as
> Ceylon to declare their own constraint validators for BV built-in
> constraints, but obviously that'd fall short when it comes to
> 3rd-party custom constraints for basic Java datatypes.
> 
> Thoughts?
> 
> --Gunnar
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev