[bv-dev] Method validation - cont'd

[Matt Benson]

On Tue, May 15, 2012 at 2:58 PM, Gunnar Morling
<gunnar.morling at googlemail.com> wrote:
> 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.

Good point.  Certainly there are ways and ways, which could of course
potentially become so convoluted as to make the whole endeavor less
than worthwhile.  ;)  I'll keep chewing on this one.

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

Yes, I see you're correct; I had been thinking that the method name
would figure into the matching of the validation method and thus that
a constructor name would be a problem.  But since the matching is
described as taking place by signature only, I agree that's not a
problem.

Obviously my only complaint wrt option #3 is the topographical and
thus less-than-perfectly-enforceable nature of the mapping to
validation methods.

Matt

>
> --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
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev