[bv-dev] Method level validation

[Emmanuel Bernard]

Yes the link between the marker annotation and the main annotation is not obvious to the code reader. I was thinking about an annotation on the marker annotation itself but that's a bit hidden to the user.

On 25 sept. 2011, at 13:30, Gunnar Morling wrote:

> I think this would make things quite complex.
> 
> Users would have to provide two annotations and a validator. How would
> the validators look for the given example? I'm also unsure about how
> well that actually reads. How does one know that @Duplicated.Duplicate
> relates to @Duplicated?
> 
> --Gunnar
> 
> 2011/9/16 Emmanuel Bernard <emmanuel at hibernate.org>:
>> That's a nice idea
>> class User {
>>     @Duplicated
>>     String password;
>>     @Duplicated.Duplicate
>>     String duplicatedPassword;
>> }
>> class {
>>     @Causality
>>     Date checkIn;
>>     @Causality.After
>>     Date checkout;
>> }
>> This exact model does not scale if several string or dates need to be
>> compared and is weak on inheritance. A full scale qualifier model might be
>> nice but it's one or two additional annotations to define per type.
>> Thoughts?
>> 
>> On 8 sept. 2011, at 22:15, Gerhard Petracek wrote:
>> 
>> as an alternative we could think about a solution >similar< to cdi
>> qualifiers. that would be also useful for cross-field validation.
>> i would like to suggest a wiki which shows all possibilities side by side (+
>> examples).
>> regards,
>> gerhard
>> 
>> 
>> 
>> 2011/9/8 Hardy Ferentschik <hardy at hibernate.org>
>>> 
>>> On Wed, 07 Sep 2011 22:55:47 +0200, Sebastian Thomschke
>>> <sebastian.thomschke at web.de> wrote:
>>> 
>>>> Its a very unfortunate limitation in Java's reflection API that it does
>>>> not provide the ability to determine the declared parameter names. OVal
>>>> provides a pluggable parameter name resolver, with a very simple
>>>> interface:
>>>> 
>>>> public interface ParameterNameResolver
>>>> {
>>>>      String[] getParameterNames(Constructor< ? > constructor) throws
>>>> ReflectionException;
>>>>      String[] getParameterNames(Method method) throws
>>>> ReflectionException;
>>>> }
>>> 
>>> I like the idea of introducing an interface for parameter name resolution.
>>> The default and simple implementation would be the enumerated names.
>>> Other implementations could be based on byte code enhancing (like
>>> mentioned here)
>>> or a meta model created by an annotation processor (like Kevin suggested
>>> in HV-409).
>>> 
>>> --Hardy
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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
>> 
>> 
>> _______________________________________________
>> 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