I want to trap all changes to properties of a particular entity and generate audit records, e.g. field name, old value, new value. I want to do this by creating new entity instances and persisting them.

I would have expected some type of simple listener that would be notified of updates, but I don't see one. So I thought maybe I'm expected to use something like PropertyChangeSupport?

According to the EJB3 PR Persistence Spec in section 3.4 (last bullet point) a callback method cannot invoke the EntityManager. So even if I were to buffer the list of edits, I could not use the EntityManager to persist them.

Obviously this is a pretty common scenario, so I'm hoping there is an easier way.

Anyone have some insight?

Thanks!

@EntityListener
@PrePersist
@PreUpdate

The PreXXX/PostXXX callback methods are exactly what is referenced by the spec as being places where you cannot invoke the EntityManager. So I can't buffer changes until @PreUpdate, then flush them using EntityManager.persist(x).

Aside from that, isn't there some way in EJB3 (or even the Hibernate API) to get the list of modified properties, just before a save? I cannot generate the audit records until the modified entity is being written. Meaning, it cannot generate the audit records when fields are modified, because it cannot be determined at that moment whether the modified entity is going to be persisted or not (I mean, by the end of the transaction it might be deleted, or reset back to it's persistent state, etc).

Use an Hibernate Interceptor for that.

Uh, according to the org.hibernate.Interceptor class javadocs, I can't do that either:

"The Session may not be invoked from a callback (nor may a callback cause a collection or proxy to be lazily initialized)."

no, but you can create a new one on the same JDBC connection. There are some materials explaining that

So the conclusion is that there is no facility in EJB3 for doing this?

I hope I'm missing something, because this is SO fundamental. Perhaps it's slated for PR2?

Is there a public forum for EJB3 feedback, or do we just send emails into the black hole that is jsr-220-comments@jcp.org?

This may be SO fundamental, but think about it, reusing a persistence context and changing its state on such events, esp when the PC is on its way to flush the events on DB is SO complex to handle in a performant manner.
Some implementations may allow you to create a differnet PC and work with it, but I'm not sure it will be allowed by the spec in a portable manner.

Maybe try to ask your DBA for some trigger-based implementation, It seems to be that auditing is much more efficiently handle at the DB level.

What I expect from EJB3 is a spec for building portable database applications.

"Portable" has two applications: (1) that I can use different EJB3 providers, and (2) that my application will run without modification against a variety of databases. Item 2 is much more important than item 1, to me. It's not desirable to put anything into the code that is DB vendor specific. This is a priority whether we use Hibernate, or EJB3, or some other persistence provider.

Many apps have entities with "created" or "last modified" fields that need to be updated. And many entities need detailed change events logged to an audit table. I think we should be able to define a generic listener, that in the callback can (a) update entities, and (b) create new entity instances and persist them. And as part of that callback API it should even provide a mechanism to detect which properties have been modified, and their old and new values.

I believe this is a common issue. And now is the time to focus on "what ought to be", while EJB3 is still in it's formative stage, right?

This can be done by calling EntityManagerFactory.createEntityManager() and getting a temporary EM for use during the callback.

In fact its the same old pattern that is on the Wiki in some interceptors, and in chapter 8 in Hibernate in Action, and in the AuditLog interceptor example code in CaveatEmptor.

When you say "it's the same old pattern ...", are you saying RTFM, or are you agreeing that it would be nice for EJB3 to support this?

I did find some useful stuff (for EJB3) in CaveatEmptor, but I did not see an EJB3 example showing detail change logging.

The problem seems to be assigning the interceptor (which is all over the place for Hibernate). I opened a JIRA case yesterday.