[Hibernate-JIRA] Created: (HV-549) add method ValidatorImpl.validateElement(Annotation[], Class<?>, Type, Object value, Class<?>... groups)
12:19 p.m.
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
3:58 a.m.
New subject: [Hibernate-JIRA] Commented: (HV-549) add method ValidatorImpl.validateElement(Annotation[], Class<?>, Type, Object value, Class<?>... groups)
[
http://opensource.atlassian.com/projects/hibernate/browse/HV-549?page=com...
]
Hardy Ferentschik commented on HV-549:
--------------------------------------
Hi,
to be honest, I don't fully understand what you are proposing and why. I guess you are
not talking about _validte_ and _validateAllParameters_, but rather _validateProperty_ and
_validateParameter_.
{quote}
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.
{quote}
The properties are not just placeholders. They are abstractions. The idea behind Bean
Validation is to be _Bean_ (object) centric and hence you provide property paths. In your
case you pass the constraints to validate via an array of annotations. How do you
determine this array? You would have to process the bean yourself and consider things like
inheritance and implemented interfaces yourself. Why not letting the bean validation
framework taking care of this? Also, annotations seems to be the wrong abstraction either
way. What's about XML configuration or the programmatic configuration?
Do you have any convincing usecase for your suggestion?
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
10:45 a.m.
New subject: [Hibernate-JIRA] Commented: (HV-549) add method ValidatorImpl.validateElement(Annotation[], Class<?>, Type, Object value, Class<?>... groups)
[
http://opensource.atlassian.com/projects/hibernate/browse/HV-549?page=com...
]
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
11:07 a.m.
New subject: [Hibernate-JIRA] Commented: (HV-549) add method ValidatorImpl.validateElement(Annotation[], Class<?>, Type, Object value, Class<?>... groups)
[
http://opensource.atlassian.com/projects/hibernate/browse/HV-549?page=com...
]
Hardy Ferentschik commented on HV-549:
--------------------------------------
{quote}
Check that a String value is a valid @Email
{quote}
Instantiate a _EmailValidator_, initialize it with the annotation and then call
_isValid_.
I just don't see how your proposal fits into the Validator interface. It would create
a lot in inconsistencies with the metadata api and also constraint violations. To even
consider it, I would like to see some complete examples and how it would fit into the
current API.
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
11:09 a.m.
New subject: [Hibernate-JIRA] Updated: (HV-549) add method ValidatorImpl.validateElement(Annotation[], Class<?>, Type, Object value, Class<?>... groups)
[
http://opensource.atlassian.com/projects/hibernate/browse/HV-549?page=com...
]
Hardy Ferentschik updated HV-549:
---------------------------------
Component/s: engine
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
Components: engine
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
11:18 a.m.
New subject: [Hibernate-JIRA] Commented: (HV-549) add method ValidatorImpl.validateElement(Annotation[], Class<?>, Type, Object value, Class<?>... groups)
[
http://opensource.atlassian.com/projects/hibernate/browse/HV-549?page=com...
]
George Sapountzis commented on HV-549:
--------------------------------------
I know there are workarounds but they have problems. IIRC "Instantiate a
EmailValidator, initialize it with the annotation and then call isValid" requires
that the isValid method does not use the validation context or checks for a null context
or the caller builds a mock validation context.
Alternatively, bean validation could provide more generic extension points in the same
fashion that data binders do.
I agree though that the proposal is rough and vague. Feel free to close it as invalid.
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
Components: engine
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
11:29 a.m.
New subject: [Hibernate-JIRA] Resolved: (HV-549) add method ValidatorImpl.validateElement(Annotation[], Class<?>, Type, Object value, Class<?>... groups)
[
http://opensource.atlassian.com/projects/hibernate/browse/HV-549?page=com...
]
Hardy Ferentschik resolved HV-549.
----------------------------------
Resolution: Incomplete
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
Components: engine
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
4666
days inactive
4695
days old
hibernate-issues@lists.jboss.org
6 comments
2 participants
participants (2)
-
George Sapountzis (JIRA) -
Hardy Ferentschik (JIRA)