[hibernate-issues] [Hibernate-JIRA] Commented: (HV-549) add method ValidatorImpl.validateElement(Annotation[], Class<?>, Type, Object value, Class<?>... groups)

[George Sapountzis (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HV-549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44825#comment-44825 ] 

George Sapountzis commented on HV-549:
--------------------------------------

[How do you reply inline in JIRA ?]

> to be honest, I don't fully understand what you are proposing and why.

That's ok, I am not famous for my clarity :-)

> Do you have any convincing usecase for your suggestion?

- Check that a String value is a valid @Email

This would be like validateElement(new EmailLiteral(), ...)
(using javax.enterprise.util.AnnotationLiteral)

- In a JAX-RS MessageBodyReader, you have
  T readFrom(Class<T> type, Type genericType, Annotation annotations[], ...)

This would be like validateElement(annotations, ...)

I know both of the above can be implemented with current API but I'd like to avoid defining extra beans/methods or interceptors.

Being vague again, I presume that the validator introspects bean properties and method parameters (which are both like tuples) and constructs a meta-model. What I say is to give an API to the meta-model level directly for cases where someone else has done the work.



> add method ValidatorImpl.validateElement(Annotation[], Class<?>, Type, Object value, Class<?>... groups)
> --------------------------------------------------------------------------------------------------------
>
>                 Key: HV-549
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-549
>             Project: Hibernate Validator
>          Issue Type: New Feature
>            Reporter: George Sapountzis
>
> ValidatorImpl currently supports methods for validating bean properties / method parameters. Looking from the outside, I don't see a strong reason for using bean properties / method parameters other than that these elements are annotation placeholders.
> Using TypeLiteral/AnnotationLiteral helper classes it seems possible to construct all the necessary metadata for a validation point programmatically. So, I propose to add a generic method where the annotations/type are passed by the user. The passed value need not be a bean, it could be a *primitive* value. The resulting set of constraint violations will just have a null root bean / method.
> Hope you consider this a valid case and add such a method, or advise on an alternative way to achieve the same functionality. I'd like to do this without writing straw beans/methods and introspecting them just for the sake of adapting to the API. I am not able to find my way around to achieving this currently.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira