[bv-dev] Group conversion on overridden method

Gunnar Morling gunnar at hibernate.org
Tue Jan 29 03:35:46 EST 2013


FYI, I've created https://hibernate.onjira.com/browse/BVAL-365 to clarify
the related wording.


2013/1/29 Gunnar Morling <gunnar at hibernate.org>

> Ok, thanks. How is it with specifying @Valid on parallel types:
>
> interface IFoo1 {
>     @Valid
>     public Bar getBar() {}
> }
>
> interface IFoo2 {
>     @Valid
>     public Bar getBar() {}
> }
>
> class FooImpl implements IFoo1, IFoo2 {
>     @Override
>     public Bar getBar() {}
> }
>
> Is this legal? The wording in 4.5.5 seems a bit unclear:
>
> > One must not mark a method return value for cascaded validation more
> than once in a class hierarchy.
>
> This would render the situation above illegal. But then it goes on:
>
> > In other words, sub types (be it sub classes/interfaces or interface
> implementations) cannot mark the return value for cascaded validation if
> the return value has already been marked on a super type or interface.
>
> This describes only the subtype situation, not addressing the situation
> above and thus implying that it is legal. Maybe we just remove the second
> sentence? I think it is also understandable on its own right due to the
> other cases before.
>
> Note that constraint mappings are explicitly forbidden for parallel
> hierarchies in section 4.4.5.
>
> Emmanuel, what was our intention when forbidding to specify @Valid several
> times? Forbidding several occurrences of @ConvertGroup makes sense to me
> due to the LSP, but several @Valid don't seem problematic to me.
>
> Or was it to "transitively" cover the @ConvertGroup case since we also say
> that @ConvertGroup may only be given where @Valid is specified?
>
> I think it would make sense to either
>
> * Forbid several occurrences of @Valid (subtypes, parallel hierarchies);
> Allow @ConvertGroup only where @Valid is given; Don't have additional rules
> for @ConvertGroup
>
> OR
>
> * Allow several occurrences of @Valid; Allow @ConvertGroup only where
> @Valid is given; Forbid several occurrences of @ConvertGroup (subtypes,
> parallel hierarchies)
>
> WDYT?
>
> --Gunnar
>
>
> 2013/1/28 Emmanuel Bernard <emmanuel at hibernate.org>
>
>> Yes that was the idea to only offer the first variant as valid. If the
>> spec is too unclear open an issue.
>>
>> On 28 janv. 2013, at 17:51, Gunnar Morling <gunnar at hibernate.org> wrote:
>>
>> > Emmanuel, all,
>> >
>> > I need a short confirmation related to the definition of group
>> conversions for the return value of an overriding method. IIUC, the
>> following is legal:
>> >
>> > Class Foo {
>> >     public Bar getBar() {}
>> > }
>> >
>> > Class SubFoo extends Foo {
>> >
>> >     @Valid
>> >     @ConvertGroup(from=..., to=...)
>> >     @Override
>> >     public Bar getBar() {}
>> > }
>> >
>> > That is, SubFoo can define a group conversion for the return value as
>> @Valid itself is added in SubFoo only. It would be illegal if @Valid was
>> given in Foo, too.
>> >
>> > I think that makes sense since LSP is not violated by the first
>> variant, while it would in the second (a user of Foo wouldn't be aware of
>> the applying conversions).
>> >
>> > Right?
>> >
>> > Thanks,
>> >
>> > --Gunnar
>> >
>> > _______________________________________________
>> > 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20130129/2828956f/attachment.html 


More information about the beanvalidation-dev mailing list