ReadAudit is a feature where read access is logged for auditing purposes. You can annotation entity beans with @ReadAudit and then read events on these beans (queries and hits in L2 cache) are logged.

An implementation of the ReadAuditPrepare interface is typically required. The readAuditPrepare.prepare() method is expected to populate the ReadEvent with user context information (user id, user ip address etc).


SqlQuery queries are currently not logged to the read audit log (RawSql queries are included in read auditing).

Getting started

Step 1: Add @ReadAudit

Add @ReadAudit annotation to all the entity beans that should have read auditing.

@Table(name = "customer")
public class Customer {

Step 2: Implement ReadAuditPrepare

If you skip this step and don't supply a ReadAuditPrepare implementation a 'no op' implementation is used and the user context information (user id, user ip address etc) is left unpopulated.

class MyReadAuditPrepare implements ReadAuditPrepare {

  public void prepare(ReadEvent event) {

    // get user context information typically from a
    // ThreadLocal or similar mechanism

    String currentUserId = ...;

    String userIpAddress = ...;


    // add arbitrary user context information to the
    // userContext map
    event.getUserContext().put("some", "thing");

Step 3: Register ReadAuditPrepare implementation

The implementation of ReadAuditPrepare can be automatically detected if classpath scanning is on (just like entity beans are found etc). That is, if scanning is on you don't need to explicitly register the ReadAuditPrepare implementation and instead it will be found and instantiated.

If scanning is not used or the ReadAuditPrepare implementation has dependencies and its instantiation should be performed externally to Ebean then you can register it explicitly with the ServerConfig.

// example code explicitly registering the ReadAuditPrepare implementation

MyReadAuditPrepare readAuditPrepare = ...;

ServerConfig config = new ServerConfig();

// register explicitly here

EbeanServer server = EbeanServerFactory.create(config);

Step 4: Configure logging

The default implementation of ReadAuditLogger logs query plan entries to org.avaje.ebean.ReadAuditQuery and read events to org.avaje.ebean.ReadAudit. The query plans contain the full SQL and having these logged separately means that the read events don't need to include the full SQL executed and instead the bean type and query key can be used to reference/lookup the associated SQL. This reduces the bulk/size of the read event logs.

Below in logback xml configuration is 2 appenders. READAUDIT_QUERY_LOG for logging the query plans and READAUDIT_LOG for logging the read bean events.

<!-- LOGBACK configuration: separate loggers for the read auditing -->

<appender name="READAUDIT_QUERY_LOG" class="ch.qos.logback.core.rolling.RollingFileAppender">
  <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
  <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
    <pattern>%d{HH:mm:ss.SSS} %msg%n</pattern>

<appender name="READAUDIT_LOG" class="ch.qos.logback.core.rolling.RollingFileAppender">
  <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
  <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
    <pattern>%d{HH:mm:ss.SSS} %msg%n</pattern>

<logger name="org.avaje.ebean.ReadAuditQuery" level="TRACE" additivity="false">
  <appender-ref ref="READAUDIT_QUERY_LOG"/>

<logger name="org.avaje.ebean.ReadAudit" level="TRACE" additivity="false">
  <appender-ref ref="READAUDIT_LOG"/>

Optional: ReadAuditLogger implementation

If the default logging does not suit you can implement ReadAuditLogger to control how the events are logged. Log to a message queue, direct to a data store etc.


For a specific query you can explicitly exclude it from the read auditing. The typically use case for this is where the query is used internally in the application to populate a cache or process bulk data and where you don't want that to go into the read audit log.