Hi!
Imagine you have to build a web version of SunBird, its core is pretty simple, it helps you plan what are you going to do on a particular date at a particular hour (in a particular place).

So, you build the first stable version of your application and you and it over to you testers, and they try to do this:

• Meeting 2008/May/10 at the Bank of America from 10 AM to 11 AM
• Meeting 2008/May/10 at the Safeguard Insurance from 10:30 AM to 11:30 AM

Ups.... you have a problem you can not be in both places at the same time... and before you can think of the answer to that, your boss arrives and tells you: "we have a new requirement from marketing" if this is a web version, it should have collaboration capabilities, and therefore it should be possible to easily find a moment when everybody is available for a meeting.

So, now, you have 2 problems: the system most tell you if you have a conflict in the schedule of a particular user, and it must also tell you, if you need a meeting between many users,if a particular time and date is free from conflicts.

This can be easily solved with a couple of SQL queries, but you are coding with Hibernate, and you want to use Hibernate Validation..., all you have to do, is send a message like this when a conflict is found (I use {} from contextual information):

"I am sorry but your meeting at {Safeguard Insurance} on {2008/May/10} at {10:30 AM to 11:30 AM} has a conflict with a previously set meeting on {the same date}, from {10 AM to 11 AM} with {Bank of America}"

But suddenly you realize you cannot (should not? what is the "recommended best practice" here?) call the EntityManager in you Validators... and in that particular moment you boss arrives again and tells you: Please, do not forget that our Calendar Application will also offer a WebServices front end, and the ability to import from Excel worksheets (and it will, of course prevent any scheduling conflicts). And of course, being a good developer you know you can not deal with this doing only some client-UI calendar component tricks (after all, the client can never be trusted)

Will JSR 303 help make this kind of validation easier? (Specially without violating DRY ?)

I am not sure solving this problem really belong to a Constraint declaration.