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@hibernate.org>
On Wed, 07 Sep 2011 22:55:47 +0200, Sebastian Thomschke
<sebastian.thomschke@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev