Auditing Entities With JPA Events

This article shows how you can leverage JPA Lifecycle Events to automate the filling in of audit information. The first example uses a base entity class with lifecycle events that looks for a time stamp interface to determine whether the entity is audited.

@MappedSuperclass
public class BaseEntity implements Serializable { 
	
	@PrePersist
	protected void onPrePersist() {
		populateTimestamp();
	}
	
	@PreUpdate
	protected void onPreUpdate() {
		populateTimestamp();
	}
		
	protected void populateTimestamp() {
		if (this instanceof Timestamped) {
			Timestamped ts = (Timestamped) this;
			if (ts.getCreatedOn() == null) {
				ts.setCreatedOn(new Date());
			} else {
				ts.setUpdatedOn(new Date());
			}			
		}
	}
}

The populateTimestamp method assumes that if the createdOn value isn’t set then the entity is a newly created entity. If it is set, then this is an update.

We’ve assumed that the entity with audit informatin implements a Timestamped interface that implements the get/set createdOn and updatedOn properties. This lets us implement a listener that works on any entity that implements this interface and also means that we just need to implement that interface and the auditing will be automatic.

public interface Timestamped {
	
	public Date getCreatedOn();
	public void setCreatedOn(Date createdOn);
	public Date getUpdatedOn();
	public void setUpdatedOn(Date updatedOn);
	
}

If you don’t want to bundle the code in a common ancestor class, you can put it into a listener class.

public class EntityListener {

	@PrePersist
	public void onPrePersist(Object o) {
		populateTimestamp(o);
	}
	
	@PreUpdate
	public void onPreUpdate(Object o) {
		populateTimestamp(o); 
	}
	
	
	protected void populateTimestamp(Object o) {
		if (o instanceof Timestamped) {
			Timestamped ts = (Timestamped) o;
			if (ts.getCreatedOn() == null) {
				ts.setCreatedOn(new Date());
			} else {
				ts.setUpdatedOn(new Date());
			}			
		}
	}
}

To specify the listener for a particular entity you specify it in the entity class :

@Entity
@Listeners(EntityListener.class)
public class Product implements Timestamped {

}

A downside here is that you need to remember to manually add the listener as well as the Timestamped interface.

One limitation is that JPA listeners cannot have CDI beans injected into them which might be a problem. An alternative is if you are using a generic DAO class to handle entity persistence is to put the enhanced populateTimestamp method on there and call it prior to inserting or updating the entity in the DAO.

5 thoughts on “Auditing Entities With JPA Events

  1. Nice piece of code andy. You might need to explain the alternative better. I know code mentioning of DAO is longer but it will clear a lot.

  2. No No No,

    I use Hibernate Envers to audit entities. It works very well and it’s has many features required to get informations about entity revisions for example.
    Use already created and tested solutions :)

    1. Jose Fernandez

      Do you think JPA isn’t a “created and tested” solution? There is absolutely nothing wrong with following the guidelines in this post.

      1. Yeah, there are problems with this approach, but there are with Envers too.

        The biggest problem with auditing via an entity listener or lifecycle annotation is that, as noted in the lost entities and entity listeners are not managed beans and are not subject to CDI injection. Thankfully this will be fixed for entity listeners by JPA 2.1if it ever arrives. The experts group declined to make entities subject to injection, citing performance concerns, but agreed to permit injection into entity listeners to become part of the spec revision.

        In the mean time I you want to know WHO made a change as well as when it was made you will have to use a JNDI lookup for the security principal, or access your cdi powered application’s state via Seam 3 Solder’s BeanManagerAware helper class or a direct JNDI lookup of the BeanManager. Ick.

        Lets hope #JavaEE7 embraces “cdi everywhere” and a push toward uniform consistent interfaces for injection etc to get rid of this crap.

  3. When I implemented something very similar I used an embedded entity for the audit data, and used a listener to manipulate the embedded entity. That way you just embed it in each audited entity to get auditability. Much easier than access from the listener via an interface.

    The brain-death in Java EE 6 around CDI as it interacts with other specs was a pain though. Getting access to app state from a listenener seems like a vital and basic task, but forces a trip back into Java EE 5land as it requires EJB lookips via JNDI or the use of a Singleton. Seam 3 Solder helps with BeanManagerAware but it is still a dirty hack that should not be necessary.

    Other than that issue, using an embeddable entity worked extremely well and facilitated cleaner composition without messing with the inheritance tree or the interface of the entities.