Guide to Jersey Logging on Server

1. Introduction

In this tutorial, we’ll explore enabling, configuring, and customizing logging in a Jersey server application and demonstrate how to verify logging behavior with integration tests.

2. Scenario Setup

Let’s start with a minimal Jersey server setup. We’ll create a simple REST endpoint and configure Jersey to log incoming requests and outgoing responses. We’ll use SLF4J as our logging backend, a common choice in Java projects.

2.1. Creating an Endpoint

Our resource contains a single endpoint that returns a String, but could return any other type:

@Path("/logging")
public class LoggingResource {

    @GET
    public String get() {
        return "Hello";
    }
}

2.2. Registering the Resource

We’ll register this resource in our Jersey application configuration class:

public class JerseyServerLoggingApp extends ResourceConfig {

    public JerseyServerLoggingApp() {
        register(LoggingResource.class);

        // ...
    }
}

3. Enabling Logging in Jersey

Jersey provides a built-in logging feature via LoggingFeature, which can be registered with the application. This feature logs HTTP traffic at various levels (headers, payload, etc.), which we choose via the LoggingFeature.Verbosity enum.

We’ll register it by passing a Logger, logging level, verbosity, and max entity size. The appropriate max entity size varies depending on our application needs. If we’re logging payloads and they include a lot of data (like base-64 properties), limiting the entity size avoids ending up with huge, unreadable amounts of logs:

register(new LoggingFeature(
  Logger.getLogger(LoggingFeature.DEFAULT_LOGGER_NAME), 
  Level.INFO, 
  LoggingFeature.Verbosity.PAYLOAD_ANY, 
  8192)
);

This configuration logs all request and response payloads up to 8192 bytes (8 kiB).

4. Implementing Custom Logging

We can implement a custom ContainerRequestFilter or ContainerResponseFilter from the JAX-RS API for more control. This allows us to log specific details or format logs as required. Each interface defines a filter method that exposes a context object with information about the request or response.

4.1. Implementing ContainerRequestFilter and ContainerResponseFilter

Let’s create a custom logging filter that implements both ContainerRequestFilter and ContainerResponseFilter:

@Provider
public class CustomServerLoggingFilter 
  implements ContainerRequestFilter, ContainerResponseFilter {
    static final Logger LOG = LoggerFactory.getLogger(CustomServerLoggingFilter.class);

    // ...
}

This sets up a provider class that implements both request and response filters, and initializes a logger for use in both methods. Next, we implement the request logging method:

@Override
public void filter(ContainerRequestContext requestContext) {
    LOG.info(
      "Incoming request: {} {}", 
      requestContext.getMethod(), 
      requestContext.getUriInfo().getRequestUri());
}

This method is called for every incoming HTTP request. It logs the HTTP method and the request URI, which is helpful for tracking which endpoints are being accessed. Similarly, we implement the response logging method:

@Override
public void filter(
  ContainerRequestContext requestContext, ContainerResponseContext responseContext) {
    LOG.info(
      "Outgoing response: {} {} - Status {}", 
      requestContext.getMethod(), 
      requestContext.getUriInfo().getRequestUri(), 
      responseContext.getStatus());
}

This method is called for every outgoing HTTP response. It logs the HTTP method, the request URI, and the response status code, providing a complete picture of the request/response cycle.

4.2. Registering the Custom Filter

Finally, let’s register this filter in our application config:

register(CustomServerLoggingFilter.class);

5. Creating an Integration Test for Logging

We can write an integration test to verify logging that starts the Jersey server, makes a request, and checks the logs. Let’s start with the server setup:

class JerseyLoggingIntegrationTest {
    private static HttpServer server;
    private static final URI BASE_URI = URI.create("http://localhost:8080/api");

    @BeforeAll
    static void setup() throws IOException {
        server = GrizzlyHttpServerFactory.createHttpServer(
          BASE_URI, new JerseyLoggingServerApp());
    }

    @AfterAll
    static void teardown() {
        server.shutdownNow();
    }

    // ...
}

This sets up the integration test class, defines the server and base URI, and provides setup and teardown methods to start and stop the Jersey server before and after all tests. Now, let’s add a test that registers a logger we can use to assert our configuration works, and is called by our custom logging filter. We’ll do that with a ListAppender:

@Test
void whenRequestMadeWithLoggingFilter_thenCustomLogsAreWritten() {
    Logger logger = (Logger) LoggerFactory.getLogger(CustomServerLoggingFilter.class);
    ListAppender<ILoggingEvent> listAppender = new ListAppender<>();

    listAppender.start();

    logger.addAppender(listAppender);
    listAppender.list.clear();

    Response response = ClientBuilder.newClient()
      .target(BASE_URI + "/logging")
      .request()
      .get();
    assertEquals(200, response.getStatus());
    
    // ...
}

Here, we configure a ListAppender to capture logs from the CustomServerLoggingFilter logger, start it, and clear any previous logs. We then request a GET to the /logging endpoint and assert that the response status is 200.

Ultimately, we can iterate over our logs and check for the existence of the ones created by our filter:

boolean requestLogFound = listAppender.list.stream().anyMatch(
  event -> event.getFormattedMessage().contains(
    "Incoming request: GET http://localhost:8080/api/logging"));

boolean responseLogFound = listAppender.list.stream().anyMatch(
  event -> event.getFormattedMessage().contains(
    "Outgoing response: GET http://localhost:8080/api/logging - Status 200"));

assertEquals(true, requestLogFound);
assertEquals(true, responseLogFound);

logger.detachAppender(listAppender);

We check that the expected log messages for both the incoming request and outgoing response are present in the captured logs. We then detach the appender to clean up after the test.

6. Conclusion

In this article, we saw how Jersey makes enabling and customizing server-side logging easy. The built-in LoggingFeature is sufficient for most use cases, but custom filters provide complete control for advanced scenarios.

As always, the source code is available over on GitHub.