Logging Configuration with DropWizard.

 

DropWizard is a library that web applications compile with as a dependency. It uses Jetty HTTP library to embed an HTTP server into the application. It uses Jersey for the interface that clients use to talk to the web server. It uses Jackson for JSON format.

It comes with a variety of configuration options that can all be used for setting up properties that the server uses to handle request and responses, logging etc. The logging configuration is especially important since application developers find that this library logs more than what they may have intended. Request logging is perhaps one such aspect and since requests may be frequently used internally by the application, the logs can grow in size by orders of magnitude.

The configurations are described well in the online documentation for the library but the application dependencies and behavior with the configuration cannot really be covered in the documentation. A developer has to resort to trial and errors to get it to work.

Among the configurations for logging, two aspects stand out primarily for the control over the verbosity of logging especially when the number of entries cannot be controlled by the application. These are logging level and logging filters. The level of the entries follows the same convention as for any other framework with graded levels. But the filters are typically implemented by the application and registered as classes so that library can log the entry if it meets a criterion or discard otherwise.

Some filters are automatically provided. These include a filter called URI which helps with the pattern matching of methods used by a client on the server’s interface.  All HTTP based methods are logged under the request logging scheme and are sometimes the biggest culprit in log bloat. The URI type used as the logging filter does not require any classes to be implemented by the Java application.

If this were as easy to follow for each and every application, the description of the caveats in this document might not be necessary. Among them, the first gotcha is that this particular configuration is not available until later versions of the library. Applications are required to upgrade transitive dependencies or force their versions even if one library version is updated. Each such version mismatch and consequent trial and error may result in a new exception when running the application requiring similar updates in other libraries or the inclusion of new ones.

When all the dependencies have been updated to their most recent version, the library may still reject certain configurations from being recognized including the URI logging filter. This is due to the discrepancy between the label used for describing the logging filter versus the implementations available in the classpath. Applications using build directives for compiling and distributing their artifacts may already be familiar with stale jars lingering between builds and particularly when a sub-project is built as opposed to the build from the project root folder. Configuration types and possible values are also not described completely requiring developers to go through the documentation, GitHub issues and fixes to be able to navigate and follow the resolution others may have determined.

These are some of the steps, an application developer can take to reduce the size of the logs.