Spring Data JPA Auditing: Automatically Saving the Good Stuff

DZone 's Guide to

Spring Data JPA Auditing: Automatically Saving the Good Stuff

Auditing provides valuable information, but it can be a nightmare to implement. Fortunately, through Spring Data JPA, you can persist the columns you need.

· Java Zone ·
Free Resource

In any business application, auditing simply means tracking and logging every change we do in our persisted records, which simply means tracking every insert, update, and delete operation and storing it.

Auditing helps us in maintaining history records, which can later help us in tracking user activities. If implemented properly, auditing can also provide us similar functionality to version control systems.

I have seen projects storing these things manually. Doing so becomes very complex because you will need to write it completely on your own, which will definitely require lots of code — and lots of code means less maintainability and less focus on writing business logic.

But why should someone need to go to this path when both JPA and Hibernate provide automatic auditing, which we can be easily configured in your project? 

Here in this article, I will discuss how we can configure JPA to automatically persist the CreatedBy, CreatedDate, LastModifiedBy, and LastModifiedDate columns for any entity.


I will walk you through to the necessary steps and code that you will need to include in your project to automatically update these properties. We will use Spring Boot, Spring Data JPA, and MySQL to demonstrate this. We will need to add the following parent and dependencies to our POM file:




Spring Data Annotations @CreatedBy, @CreatedDate, @LastModifiedBy, and @LastModifiedDate

Let’s suppose we have a File entity, and a single record in the file table stores the name and content of the file. And say we also want to store who created and modified any file at any given time. So, the goal is to keep track of when the file was created, by whom, and when it was last modified, and by whom.

We will need to add the name, content, createdBy, createdDate, lastModifiedBy, and lastModifiedDate properties to our File entity and, to make it more appropriate, we can move the createdBy, createdDate, lastModifiedBy, lastModifiedDate properties to a base class, Auditable, and annotate this base class with @MappedSuperClass. Later, we can use the Auditable class in other audited entities.

You will also need to write getters, setters, constructors, toString, and equals along with these fields. However, you should take a look at   Project Lombok: The Boilerplate Code Extractor, if you want to auto-generate these things.

Both classes will look like this:

public abstract class Auditable<U> {

    protected U createdBy;

    protected Date creationDate;

    protected U lastModifiedBy;

    protected Date lastModifiedDate;


public class File extends Auditable<String> {
    private int id;
    private String name;
    private String content;


As you can see above, I have used the @CreatedBy, @CreatedDate, @LastModifiedBy, and @LastModifiedDate annotation on their respective fields.

The Spring Data JPA approach abstracts working with JPA callbacks and provides us these fancy annotations to automatically save and update auditing entities.

Using the AuditingEntityListener Class With @EntityListeners

Spring Data JPA provides a JPA entity listener class, AuditingEntityListener, which contains the callback methods (annotated with the @PrePersist and @PreUpdate annotations), which will be used to persist and update these properties when we will persist or update our entity.

JPA provides the @EntityListeners annotation to specify callback listener classes, which we use to register our AuditingEntityListener class.

However, we can also define our own callback listener classes if we want to and specify them using the @EntityListeners annotation. In my next article, I will demonstrate how we can use @EntityListeners to store audit logs.

Auditing Author Using AuditorAware and Spring Security

JPA can analyze createdDate and lastModifiedDate using current system time, but what about the createdBy and lastModifiedBy fields? How will JPA recognize what to store in them?

To tell JPA about currently logged-in users, we will need to provide an implementation of AuditorAware and override the getCurrentAuditor() method. And inside getCurrentAuditor(), we will need to fetch a currently logged-in user.

As of now, I have provided a hard-coded user, but if you are using Spring Security, then use it to find the currently logged-in user. 

public class AuditorAwareImpl implements AuditorAware<String> {

    public String getCurrentAuditor() {
        return "Naresh";


Enable JPA Auditing by Using @EnableJpaAuditing

We will need to create a bean of type AuditorAware and will also need to enable JPA auditing by specifying @EnableJpaAuditing on one of our configuration classes. @EnableJpaAuditing accepts one argument, auditorAwareRef, where we need to pass the name of the AuditorAware bean.

@EnableJpaAuditing(auditorAwareRef = "auditorAware")
public class JpaConfig {
    public AuditorAware<String> auditorAware() {
        return new AuditorAwareImpl();

And now, if we will try to persist or update a file object, the CreatedBy, CreatedDate, LastModifiedBy, LastModifiedDate properties will automatically get saved.

In the next article, JPA Auditing: Persisting Audit Logs Automatically using EntityListeners, I will discuss how we can use JPA EntityListeners to create audit logs and generate history records for every insert, update, and delete operation.

You can find complete code on this GitHub repository, and please feel free to give your valuable feedback.

java ,spring data jpa ,auditing ,persistent data ,tutorial

Published at DZone with permission of Naresh Joshi , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}