11:37 a.m.
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."
- this does not really address return value validation
Yes; I was under the impression that return value validation is
orthogonal to cross-parameter validation.
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.
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