Hi!
One of the problematic (perhaps only for me?) things about validation is that sometimes it is triggered on "entityManager.persist" (like not null) and other times is triggered on "flush" or "at the commit of a transaction".

I think it should be possible to delay all validations until the commit of the transaction (firing validation at different times makes it harder to have it coded at an unified place), therefore I think the use of "not null" at the database level should be discouraged.

Another thing that worries me about is what should be done when transactions fail, in a typical stateless web application, there are no problems (all objects that failed validation are disposed and reloaded in the next request, and all changes in data are applied to them from the html form) but in Swing based (or stateful web applications) one doesn't get rid of modified objects until the end of the use case/conversation... but IMHO the tradition in Hibernate is to treat exceptions as unrecoverable... will that change with the new validation framework? will we be allowed to retry the saving of our objects? (Because the way I see it the validations should automatically be called "on transaction commit" if configured to do so, and the only way to notify the user (at that point) that validations failed is with an exception).

What are your thoughts on this?
Regards,

hummmmmmm
This is an interesting problem that has more to do with JPA than anything else.
I have not easy idea to solve that, but I noted the point.