Play framework accesslog module update

A few weeks ago my first Play framework module got accepted and published. The module performs request logging similar to an access log file in nginx or apache. I just released a small update (v1.1) to the module. It now attempts to create the full log path if it doesn't exist.

This post is not meant to duplicate the documentation I already have written and published on github and playframwork.org. I will first refer you to those sites and then continue this post with a quick sample application using the module.

http://www.playframework.org/modules/accesslog
https://github.com/briannesbitt/play-accesslog

Let's now create a new Play application.

play new accessLogSample
cd accessLogSample

Now add - play -> accesslog 1.1 to your conf/dependencies.yml file.

play dependencies
play run

Now load http://127.0.0.1:9000/ in your browser. Thats it! You should see the requests and responses get logged to your configured accesslog file.

v1.0 Warning

The initial 1.0 version would have generated the following warning if you did have the full path to the log file pre-created:

23:57:55,286 WARN ~ AccessLogPlugin: No accesslog will be used (cannot open file handle) (Z:\dev\accessLogSample\logs\access.log (The system cannot find the path specified))

I have updated the module to recursively create the directory structure to the configured accesslog.path file provided. If you use the default config and are running the 1.0 version, all you need to do if you see the warning above is mkdir logs in your project root or better yet just upgrade to the lastest version.

Logging to Play console

Although having the log file populated is nice, during dev its also nice to see the logs in the console. To get this working just add accesslog.log2play=true in your conf/application.conf and restart. This will cause the logs to be written to the play.Logger at the INFO level so it also relies on your application.log=INFO being set which is the default so for most it will just work.

Production Usage

There is nothing special done in the module with respect to performance. It is threadsafe as the log method is synchronized. I could have done something more like push the log strings to an in-memory queue and run a seperate thread for the IO, but it wasn't worth the effort. Logging is done in invocationFinally() so it shouldn't slow the response to the browser as that should already be sent out. I would recommend using this in dev along with firebug / fiddler to help debug or track down any issues you might be having. If you use it in production I would do so only under a watchful eye and for a short amount of time. For a longer term production logging solution you should setup a reverse proxy like nginx and use it's logging capabilities as described here: nginx HttpLogModule.

And yes I repeated that last part, but its important enough to do so!