[bv-dev] Method level validation

[Gunnar Morling]

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
>
>