Skip to content

How to implement Log4j-audit in Java/GWT web app

Currently working on implementing audit logging for a web app and would like to use log4j-audit. The app is written using OpenJDK 8 and GWT 2.7 hosted by Jboss 6.4 and built using Ant 1.10.5. My question is how does one implement the log4j-audit framework into our current structure? I have worked through the getting started section and read the documentation exhaustively but my lack of Maven experience is making it difficult transporting it to our stack.

My current understanding is that I need to create a request filter that instantiates a RequestContext object that stores variables in a ThreadContext map. What I need to know is how to use my catalog.json to generate the interfaces that I can reference in my code.



Thanks to the info in section 1. of the marked answer below I was able to create a custom Ant task, with a POM similar to that in the sample app, that builds the audit-service-api.jar and reference the generated sources in my codebase.


The RequestContextFilter is an extension of the Log4j ThreadContext that allows you to convert headers passed in REST requests into ThreadContext attributes. This is important for auditing so that you can pass the user’s loginId, IP Address, account number, etc so that they can be included in all the audit events (as well as all the other logs). Although not necessarily important for audit logging, including a requestId and “sessionId” is important for diagnostic and debug logs to correlate logs across services and servers.

The catalog.json file is used to define the audit events and attributes. Normally you would create a project similar to log4j-audit-sample. This project contains 3 things:

  1. The Audit Service API – The catalog.json would reside in src/main/resources and contains the definitions of your events and attributes. When you run “mvn clean package”, “mvn clean install” or “mvn clean deploy” on this project it will read the catalog and generate all the Java interfaces for the events you have defined. You would then include the jar constructed from this project in your applications along with the log4j-audit-api jar to log the events.
  2. The Audit Service – A REST service that can be used to log events from non-Java applications. The service will validate the events against your catalog.

Log4j-audit comes with a Spring Boot app that can be used as an editor for the catalog as editing the JSON can be tedious and error prone. That said, the Spring Boot app needs to be run as a single user desktop app, which is a little odd, so a desktop editor based on ElectronJS is being developed.

Log4j-audit currently supports two formats for the catalog; the catalog.json file stored in git or an RDMS catalog accessed via JPA. Normally, the catalog stored in git is used to generate the Java interfaces because those should be modified only normally during the normal development process and you would want to manage those definitions with a normal release cycle. The Spring Boot catalog editor reads the json catalog from git and then loads it into an in-memory database so that the editor can take advantage of the referential integrity the database provides. The Audit Service can be configured to use a database to store a “dynamic catalog”. No Java interfaces are available for these catalog entries and applications that want to perform auditing using these event definitions must do it through the audit service.

Hopefully, that provides the information you are looking for but if you performed the steps in the Getting Started page and look at the sample application you should have an idea of what you need to do. If not, please follow up with more questions.