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.
Let's now create a new Play application.
play new accessLogSample cd accessLogSample
- play -> accesslog 1.1 to your
play dependencies play run
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.
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
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.
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!