JPA Auditing: Automatically Persisting Audit Logs Using EntityListeners

JPA Auditing: Automatically Persisting Audit Logs Using EntityListeners

http://ift.tt/2rrlzQ8

In my previous article, Spring Data JPA Auditing: Saving CreatedBy, CreatedDate, LastModifiedBy, LastModifiedDate automatically, I discussed why auditing is important for any business application and how we can use Spring Data JPA automate it.

I also discussed how Spring Data uses JPA’s EntityListeners and callback methods to automatically update the CreatedBy, CreatedDate, LastModifiedBy, and LastModifiedDate properties.

Well, in this article, I am going dig a little bit deeper and discuss how we can use JPA EntityListeners to create audit logs and keep information of every insert, update, and delete operation on our data.

I will take the File entity example from the previous article and walk you through the necessary steps and code portions you will need to include in our project to automate the auditing process.

We will use Spring Boot, Spring Data JPA (because it gives us complete JPA functionality plus some nice customization by Spring), and MySQL to demonstrate this.

We will need to add below parent and dependencies to our POM file:

Implementing JPA Callback Methods Using @PrePersist, @PreUpdate, @PreRemove

JPA provides us the functionality to define callback methods for any entity using the @PrePersist@PreUpdate, and @PreRemove annotations. And these methods will get invoked before their respective lifecycle event.

Similar to pre-annotations, JPA also provides post annotations like @PostPersist, @PostUpdate, @PostRemove, and @PostLoad. We can use them to define callback methods that will get triggered after the event.

JPA-Automatic-Auditing-Saving-Audit-Logs

The name of the annotation can tell you its respective event. For example:

And this is the same for other annotations as well.

Defining Callback Methods Inside Entity

We can define callback methods inside our entity class, but we need to follow some rules. For example, internal callback methods should always return void and take no arguments. They can have any name and any access level and can also be static.

Defining Callback Methods in an External Class and Use @EntityListeners

We can also define our callback methods in an external listener class in a manner that they should always return void and accepts a target object as the argument. However, they can have any name and any access level and can also be static.

And we will need to register this FileEntityListener class on File entity or its super class by using the @EntityListeners annotation:

Advantages of Using @EntityListeners

  • First of all, we should not write any kind of business logic in our entity classes and follow the Single Responsibility Principle. Every entity class should be a POJO (Plain Old Java Object).
  • We can have only one callback method for a particular event in a single class — e.g. only one callback method with @PrePresist is allowed in a class. Meanwhile, we can define more than one listener class in @EntityListeners, and every listener class can have a @PrePersist.

For example, I have used @EntityListeners on File and provided the FileEntityListener class to it. I I have also extended an auditable class in the File class.

The auditable class itself has an @EntityListeners on it with the AuditingEntityListener class because I am using this class to persist createdBy and the other above-mentioned properties. You can check my previous article, Spring Data JPA Auditing: Saving CreatedBy, CreatedDate, LastModifiedBy, LastModifiedDate automatically for more details.

We will also need to provide getters, setters, constructors, toString, and equals methods to all the entities. However, you may like to check out Project Lombok: The Boilerplate Code Extractor if you want to auto-generate these things.

Now we are all set and we need to implement our logging strategy. We can store history logs of the File in a separate history table: FileHistory.

Here, Action is an enum:

And we will need to insert an entry in FileHistory for every insert, update, and delete operation, and we need to write that logic inside our FileEntityListener class. For this purpose, we will need to inject either repository class or EntityManager in FileEntityListener class.

Injecting Spring-Managed Beans Like EntityManager in EntityListeners

But here we have a problem. EntityListeners are instantiated by JPA, not Spring, so Spring cannot inject any Spring-managed bean, e.g. EntityManager in any EntityListeners.

So if you try to auto-wire EntityManager inside the FileEntityListener class, it will not work:

I have also written a separate article on how to AutoWire Spring Beans Into Classes Not Managed By Spring Like JPA Entity Listeners, you can read it if you want to know more.

And I am using the same idea here to make it work. We will create a utility class to fetch Spring managed beans for us:

And now we will write history record creation logic inside FileEntityListener:

And now if we try to persist or update and file objects, these auditing properties will automatically be saved.

You can find complete code on this GitHub Repository and please feel free to provide your valuable feedback.

java

via DZone.com Feed https://dzone.com

May 27, 2017 at 10:39AM

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s