[hibernate-dev] [Validator] Applying constraints to property objects

Gunnar Morling gunnar at hibernate.org
Wed Sep 4 10:03:53 EDT 2013


2013/9/4 Hardy Ferentschik <hardy at hibernate.org>

>
> On 3 Jan 2013, at 4:10 PM, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
>
> > Something like c makes sense.
> > It similar to the notion of converter in JPA.
> >
> > But why not the following style of interfaces
> >
> >    interface Convert<From,To> {
> >        To convert(From);
> >    }
>
>
> Going back to Emmanuel mentioning @Convert.  I am wondering whether using
> explicit annotations would not be more appropriate than an SPI?
>

How exactly do you envision annotations to be used? Could you give an
example? I didn't understood Emmanuel's Convert type to be an annotation.


> It would of course be more verbose, but maybe the "converter" annotation
> could be applied on class level as well. The concern for me is really the
> ambiguity
>
>  @Size(min=3, max=10)
>   UIInput<String> name;
>
> introduces. What if @Null or @NotNull is used. Does it apply to the String
> or the UIInput instance. It is not apparent anymore from the annotations
> what
> is targeted.


That's a good question. One could define a precedence rule, e.g. apply on
the element itself and only if no suitable validator is found perform the
unwrapping. But admittedly that makes things a bit more complicated.


> We already started introducing ambiguous cases in Bean Validation with
> method validation (cross parameter constraints, exclusion from getters
> from validated methods), I am not sure we should continue on this path.
>
> Does the gain we achieve via the proposed SPI outweigh introducing even
> more border cases?
>

Are there any other approaches we could pursue? I definitely think offering
support for this kind of use case in one way or the other makes sense.


>
> --Hardy
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


More information about the hibernate-dev mailing list