[ https://issues.jboss.org/browse/AS7-4576?page=com.atlassian.jira.plugin.s... ] Scott Marlow commented on AS7-4576: ----------------------------------- I think the test should be adding a pre-persist entity listener instead. And seeing if the constraint happens after pre-persist has completed or not. The actual database changes may be applied during the EntityManager.persist or EntityManager.flush or during tx commit. The validation needs to happen after the point of pre-persist (is my read). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-4576?page=com.atlassian.jira.plugin.s... ] Marek Schmidt edited comment on AS7-4576 at 4/20/12 10:24 AM: -------------------------------------------------------------- It does, that's where the "XXX: prePersist" comes from in the logs, so the pre-persist happens during em.persist(), but there is no contraint violation immediately after that: 15:31:15,065 INFO [stdout] (http-dhcp-26-127.brq.redhat.com-127.0.0.1-8080-2) XXX: before em.persist() 15:31:15,066 INFO [stdout] (http-dhcp-26-127.brq.redhat.com-127.0.0.1-8080-2) XXX: prePersist 15:31:15,068 INFO [stdout] (http-dhcp-26-127.brq.redhat.com-127.0.0.1-8080-2) XXX: after em.persist() 15:31:15,074 INFO [stdout] (http-dhcp-26-127.brq.redhat.com-127.0.0.1-8080-2) XXX: Constraint violation! {noformat} ... @Entity @XmlRootElement @Table(uniqueConstraints = @UniqueConstraint(columnNames = "email")) public class Member implements Serializable { ... @PrePersist public void prePersist() { System.out.println("XXX: prePersist"); } } {noformat} was (Author: maschmid): It does, that's where the "XXX: prePersist" comes from in the logs, so the pre-persist happens during em.persist(): 15:31:15,065 INFO [stdout] (http-dhcp-26-127.brq.redhat.com-127.0.0.1-8080-2) XXX: before em.persist() 15:31:15,066 INFO [stdout] (http-dhcp-26-127.brq.redhat.com-127.0.0.1-8080-2) XXX: prePersist 15:31:15,068 INFO [stdout] (http-dhcp-26-127.brq.redhat.com-127.0.0.1-8080-2) XXX: after em.persist() 15:31:15,074 INFO [stdout] (http-dhcp-26-127.brq.redhat.com-127.0.0.1-8080-2) XXX: Constraint violation! {noformat} ... @Entity @XmlRootElement @Table(uniqueConstraints = @UniqueConstraint(columnNames = "email")) public class Member implements Serializable { ... @PrePersist public void prePersist() { System.out.println("XXX: prePersist"); } } {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-4576?page=com.atlassian.jira.plugin.s... ] Marek Schmidt updated AS7-4576: ------------------------------- Description: Per JPA 2.0 spec 3.6.1.2 Requirements for Automatic Validation upon Lifecycle Events, the "persistence provider must throw the javax.validation.ConstraintViolationException" ... and the validation must occur "immediately after the point" where callback method invocations, such as PrePersist have been completed. Having a Member entity with some @NonNull validator present on one of its fields, the following test shows the javax.validation.ConstraintViolationException is not thrown while invoking persist, but later inside flush(): {code} try { System.out.println("XXX: before em.persist()"); em.persist(new Member()); System.out.println("XXX: after em.persist()"); em.flush(); System.out.println("XXX: after em.flush()"); } catch(javax.validation.ConstraintViolationException x) { System.out.println("XXX: Constraint violation!"); } {code} {code} @Entity @XmlRootElement @Table(uniqueConstraints = @UniqueConstraint(columnNames = "email")) public class Member implements Serializable { ... @NotNull @NotEmpty @Email private String email; ... @PrePersist public void prePersist() { System.out.println("XXX: prePersist"); } } {code} was: Per JPA 2.0 spec 3.6.1.2 Requirements for Automatic Validation upon Lifecycle Events, the "persistence provider must throw the javax.validation.ConstraintViolationException" ... and the validation must occur "immediately after the point" where callback method invocations, such as PrePersist have been completed. Having a Member entity with some @NonNull validator present on one of its fields, the following test shows the javax.validation.ConstraintViolationException is not thrown while invoking persist, but later inside flush(): {noformat} try { System.out.println("XXX: before em.persist()"); em.persist(new Member()); System.out.println("XXX: after em.persist()"); em.flush(); System.out.println("XXX: after em.flush()"); } catch(javax.validation.ConstraintViolationException x) { System.out.println("XXX: Constraint violation!"); } {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-4576?page=com.atlassian.jira.plugin.s... ] Scott Marlow commented on AS7-4576: ----------------------------------- I see, so your test is showing that the prepersist notification occurs during the call to em.persist() and that the validation happens after the em.persist() completes. It sounds like you have discovered that the validation doesn't occur "immediately after the point". {quote} 3.6.1 Automatic Validation Upon Lifecycle Events This specification supports the use of bean validation for the automatic validation of entities upon the pre-persist, pre-update, and pre-remove lifecycle validation events. These lifecycle validation events occur immediately after the point at which all the PrePersist, PreUpdate, and PreRemove lifecycle callback method invocations respectively have been completed, or immediately after the point at which such lifecycle callback methods would have been completed (in the event that such callback methods are not present). {quote} I need to understand what they mean exactly by "immediately". ;) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-4576?page=com.atlassian.jira.plugin.s... ] Marek Schmidt commented on AS7-4576: ------------------------------------ My understanding of the spec is that transaction doesn't have to do anything with it... The PrePersist method is always invoked as part of the persist operation (Per 3.5.2), and automatic validation should occur immediately after the PrePersist invocations. I don't see how the spec would allow me to return from entityManager.persist(foo) if foo is invalid. If you look at the @PrePersit example in the spec (3.5.3 Example), you'll notice the @PrePersist being used for some kind of validation and throwing "AccountException". I understand the 3.6.1. as a kind of implicit @PrePersist listener using bean validation, so it makes sense to run at the same time as (or, "immediately after") other @PrePersist listeners. My understanding could be wrong, of course... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-4576?page=com.atlassian.jira.plugin.s... ] Scott Marlow edited comment on AS7-4576 at 4/23/12 11:33 AM: ------------------------------------------------------------- I can see two possible outcomes. If this is a bug, a [Hibernate ORM jira|https://hibernate.onjira.com/browse/HHH] could be opened (and we can close this jira). If its not, we can just close this jira. was (Author: smarlow): I can see two possible outcomes. If this is a bug, a [Hibernate ORM jira|https://hibernate.onjira.com/browse/HHH] could be opened. If its not, we can just close this jira. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-4576?page=com.atlassian.jira.plugin.s... ] Scott Marlow commented on AS7-4576: ----------------------------------- HHH-7288 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira