[bv-dev] Method validation - cont'd

[Gunnar Morling]

2012/5/15 Matt Benson <mbenson at apache.org>:
> On Tue, May 15, 2012 at 11:19 AM, Emmanuel Bernard
> <emmanuel at hibernate.org> wrote:
>> OK I see now.
>> I am not sure I adhere to it but that's definitely interesting.
>>
>> Some additional info:
>>
>> - this can become a bit annoying or tricky if the method we want to validate methods from has non default constructors setting final attributes - the validator implementation would have to fake some of that
>
> Hmm, yes.  Perhaps replace Initializable:
>
> public interface ParameterValidator<A extends Annotation, T> {
>
>    void initialize(A constraintAnnotation, T target);
>
> }
>
> public class ValidateReservationDates extends ReservationService
> implements ParameterValidator<DateParameterCheck, ReservationService>
> {
> ...
> }
>
> This way the validator would have access to anything externally
> accessible from a given implementation of T.  This also gives us a
> toehold to enforce the relationship between the validator and
> validated type such that "an implementation of ParameterValidator must
> be assignable to its own T parameter."

I think tying a method validator to a type would limit its reusability
for methods with the same signature defined on other types.

One general problem of the sub-classing approach is that it omits the
ConstraintValidatorContext parameter from the validation methods.
Option #3 from the original proposal adds this to the signature of the
validated methods:

ReservationService#bookHotel(Customer customer, Date from, Date to);

vs.

DateParameterCheckValidator#isValid(Customer customer, Date from, Date
to, ConstraintValidatorContext context);

Maybe this context could be set somehow externally, though.

>
>> - this does not really address return value validation
>
> Yes; I was under the impression that return value validation is
> orthogonal to cross-parameter validation.

I think so, too.

>
> Also, none of the approaches discussed seems to perfectly fit with
> constructor CP validation, but particularly if we developed this
> approach all the way to specifying the use of proxies at the spec
> level, dynamically-generated subclasses could perhaps handle it.
>

How does #3 handle method and constructor cross-parameter validation
differently? I think the approach would work for both.

--Gunnar


> Matt
>
>>
>> On 15 mai 2012, at 17:57, Matt Benson wrote:
>>
>>> On Tue, May 15, 2012 at 3:44 AM, Emmanuel Bernard
>>> <emmanuel at hibernate.org> wrote:
>>>>
>>>> On 14 mai 2012, at 18:21, Matt Benson wrote:
>>>>
>>>>>>
>>>>>> Interesting point, the more so because I was about to suggest a
>>>>>> proxy-based variation of cross-parameter validation approach #3.
>>>>>> Maybe interface-only per spec, with subclassing as an optional
>>>>>> extension.  Thoughts?
>>>>>>
>>>>>
>>>>> Actually, ruminating further on this... the approach I was thinking of
>>>>> would require at least a partial implementation of a given class, just
>>>>> to handle validation (any method result being discarded).  The
>>>>> subclassing capability would be necessary regardless of whether only
>>>>> interfaces were supported, so final methods would be the only thing
>>>>> off-limits.
>>>>
>>>> You have lost me :) Can you detail further what you are proposing, maybe with some examples.
>>>
>>> Okay, I have tried to organize my thoughts to some degree at
>>> https://cwiki.apache.org/confluence/display/BVAL/inheritance-based+cross-parameter+method+validation
>>> .
>>>
>>> Matt
>>>
>>>> _______________________________________________
>>>> 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