[bv-dev] Method validation - cont'd

[Gunnar Morling]

2012/5/14 Matt Benson <mbenson at apache.org>:
> On Mon, May 14, 2012 at 11:17 AM, Matt Benson <mbenson at apache.org> wrote:
>> On Mon, May 14, 2012 at 11:01 AM, Emmanuel Bernard
>> <emmanuel at hibernate.org> wrote:
>>>
>>> On 14 mai 2012, at 17:53, Matt Benson wrote:
>>>
>>>> On Mon, May 14, 2012 at 10:48 AM, Emmanuel Bernard
>>>> <emmanuel at hibernate.org> wrote:
>>>>>
>>>>> On 14 mai 2012, at 17:18, Matt Benson wrote:
>>>>>
>>>>>>>>
>>>>>>>> * Should method validation methods be defined on j.v.Validator or a
>>>>>>>> dedicated new interface?
>>>>>>>
>>>>>>> Should be on javax.validation.Validator
>>>>>>
>>>>>> Destroying backward compatibilty?  Not such a big deal for full-blown
>>>>>> implementations, perhaps, but what about interoperability libraries
>>>>>> that may, for whatever reason, implement javax.validation.Validator?
>>>>>> Shouldn't a user be able to upgrade to a Bean Validation 1.1
>>>>>> implementation and still use libraries built against Bean Validation
>>>>>> 1.0?
>>>>>
>>>>> No I don't think that's a realistic goal. It would force us to use some untyped unwrap() style method to
>>>>> add features to Bean Validation.
>>>>
>>>> But isn't that the reason #unwrap() is part of the Validator and
>>>> ValidatorFactory interfaces?
>>>
>>> The reason we put it in there is for implementors to be able to offer extensions more easily. Of
>>> course we could use unwrap to do as you said but it seems to me that would undermine the UX
>>> to please frameworks wrapping BV calls. note that they could use a dynamic proxy instead of a
>>> static delegator pattern to be API change proof.
>>
>> 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.

Could you give some more details on the approach you have in mind?
Maybe some interfaces/methods etc. you're thinking about?

--Gunnar


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