bval-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <>
Subject Re: An interesting post about validating collections
Date Sat, 08 May 2010 08:03:50 GMT
Oki Carlos, I see your point. For the simple List, Map, Enumeration or Set you are perfectly

But this can easily become a solution which tries to solve even more complex solutions. For
example if you have such a 


where 1 entry must be a valid email, and another one must be a valid status string, whatever...
See what I mean? So people will start whining "hey we now can validate that all strings are
emails, but we additionally need a way to only say that half of the strings must be valid

For the List problem, what about meta annotations?

We have an additional @ListValidation marker flag and by writing

public @interface EmailList {}

bval knows then that EmailList is the List<x> version of an @Email validation.

So if you have a 

public class MyBean {
  private List<String> emails;

If the validation annotation has some payload, then the list validation must provide exactly
the same.

just a weird idea...


--- Carlos Vara <> schrieb am Fr, 7.5.2010:

Von: Carlos Vara <>
Betreff: Re: An interesting post about validating collections
Datum: Freitag, 7. Mai, 2010 17:54 Uhr

IMHO it isn't business logic, but a pretty valid concern about something that the standard
cannot currently solve.

To explain myself, take the example given in Hibernate's blog, if emails weren't stored in
a String but on their own class, we already have a solution with @Valid.

public class User {
    private String name;

    private List<Email> emailList;

}But if you want to validate a type which you cannot annotate, there is no "clean" way of
doing it. Solving it by writing a custom validator like @ListOfEmailStrings (which is what
I have been doing atm) is not a good solution as you have to replicate the validation logic
of all the annotations that the individual email has.

To put this in perspective, if a single email was annotated like this:


String email;

The custom validator for the list of emails will have to replicate the validation logic of
those two constraints (as it should never instantiate the validators), and it would also have
to be manually mantained to always validate your definition of an email.

I personally think that implementing the first solution is a clean way of doing it and fits
the role of the library. Of course, that involves waiting, but waiting to be able to do something
right is never bad in my book :-)

I hope that Hibernate guys don't rush a suboptimal solution like the other ones exposed, as
it would be a clear point of incompatibility with Apache's version.


On Fri, May 7, 2010 at 3:19 PM, Gerhard Petracek <> wrote:

we are currently discussing it in the eg.maybe we should just wait for [1].

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

2010/5/7 Mark Struberg <>

I honestly think this goes into the wrong direction.

This is business logic, and if we start to provide annotations for all those kinds of problems,
it will end up getting terribly complicated.

I'd prefer to keep it simple and stupid.




>Von: Carlos Vara <>


>Gesendet: Freitag, den 7. Mai 2010, 10:57:11 Uhr

>Betreff: An interesting post about validating collections




>Currently as an user, I was solving this by writing custom validators, which it seems
is no more of a hack than the other proposed solutions (except the one that implies waiting
for JDK7 to hopefully implement JSR-308).


>Any of you guys have an idea of how we could implement it?


View raw message