2:58 p.m.
2012/5/15 Matt Benson <mbenson(a)apache.org>:
On Tue, May 15, 2012 at 11:19 AM, Emmanuel Bernard
<emmanuel(a)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(a)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-...
>> .
>>
>> Matt
>>
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev