Bug 535998 WLS 12.2.1.2 DOES NOT PROPERLY IMPLEMENT JSR 303 ISSUE #185
Conversation
Signed-off-by: Sureshkumar Balakrishnannair <[email protected]>
|
Issue tracker reference: |
1 similar comment
|
Issue tracker reference: |
|
I'm not sure this change follows the spec yet. Anyone else is? |
Signed-off-by: Sureshkumar Balakrishnannair <[email protected]>
|
Applied the formatter [EclipseLink-Eclipse-Format.xml] as specified . In this particular case we are not seeing triggering of events anywhere while updating the entity - Thanks |
| try { | ||
| e1.setName(invalidName); | ||
| e1.setSurname(invalidName); | ||
| em.persist(e1); |
There was a problem hiding this comment.
No em.merge(e1)? The entity is already managed at this point. I ran a quick local test and I don't see EclipseLink calling @PrePersist twice when there are multiple persists for the same managed entity. I can verify that with EclipseLink's implementation as well. Take a look at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.registerNotRegisteredNewObjectForPersist:
/**
* INTERNAL:
* Called only by registerNewObjectForPersist method,
* and only if newObject is not already registered.
* Could be overridden in subclasses.
*/If the object being persisted is already registered, we don't execute the PrePersistEvent.
| @@ -342,6 +343,32 @@ public void testTraversableResolverPreventsLoadingOfLazyRelationships() { | |||
| assertTrue( "Lazy field should not be instantiated because of validation", !isInstantiated(employee, "projects", project) ); | |||
| assertTrue( "Lazy field should not be instantiated because of validation", !isInstantiated(employee, "managedProject", project) ); | |||
| } | |||
|
|
|||
| public void testPesistWithInvalidAndModifiedBeanData() { | |||
There was a problem hiding this comment.
Is this a different test than BeanValidationJunitTest.testUpdateWithInvalidData()? They seem to be trying to test the same thing, but testUpdateWithInvalidData doesn't seem to be using callbacks and is instead expecting validation on transaction commit. Is this right?
According to 3.6 of the spec:
These lifecycle validation events occur immediately after the point at which all the
PrePersist, PreUpdate, and PreRemove lifecycle callback method invocations respectively
have been complete
I'm wondering if this means testUpdateWithInvalidData is wrong.
There was a problem hiding this comment.
I saw a javadoc somewhere saying that current behaviour is expected and intended by the spec - prepersist is called on the first persist call and not during transaction commit, so subsequent updates to the entity, is is done here are not validated as some people would expect. I just don't know, where I saw that comment :-/
There was a problem hiding this comment.
There was a problem hiding this comment.
@lukasj I see! I think there is a misconception then that validation occurs on transaction commit. After reading the spec, it seems pretty clear that validation occurs on the EntityManager operation invocations. However, I searched around online for some examples and it seems transaction commit is being expected by users. Given the comment you found, it certainly sounds like the current spec design has issues that we may want to address in the future.
For example, here is a Hibernate example I found. It seems the example they are using is expecting transaction commit. Perhaps Hibernate is not adhering to the spec? Idk.
|
The conclusion here is : the spec need to evolve/clarify for this case and we need to wait up to that time ? , Please help to confirm |
Signed-off-by: Sureshkumar Balakrishnannair [email protected]