I just added a pull request for the 4.3.x stream that should maintain backwards compatibility for anyone that doesn't care about the change. I went with the separation of the success/fail paths even though I can't think of what i'd ever do with an entity in the case of a failed commit.

Do you want me to do a master flavor as well? There's some API changes in Integrator that my tests use but other than that it should be identical otherwise.

The real question is whether or not the 'legacy' behavior is required going forward, I separated the test so that the Legacy one can be simply deleted. In addition, I would think the postCommitListenerRequired method should move down to the new post commit listener interfaces? I looked to see what was implementing that and it looked like the only 'real' implementation is a set of JpaPostXEventListener. However, there doesn't seem to be a distinction in JPA for postX and postCommitX so I'm not sure it belongs there anyways. i.e. things I would do in a PostUpdateEvent would be to create an audit log of changes, however a PostCommitUpdate I might send a message to an external system that a change was made (i.e. in my case, notify a Quartz Scheduling Impl) that I only ever want to send if the commit actually succeeds.

The other change going forward would be to change the POST_COMMIT_X hooks to assert against the new type and remove the instance checking from the action events.