feature/log4j over slf4j

[alexanderscott]

Common logging pattern via slf4j with log4j backend (compatibility with pretty much all java & scala apps).

Also quiets the logging from RedisWorkerIO reconnection as client connection timeouts are a very common occurrence in older versions of Redis or when set in redis.conf.

[coveralls]

Coverage decreased (-0.12%) when pulling 54ff7c3 on alexanderscott:feature/log4j-over-slf4j into f1f7bb8 on etaty:master.

[etaty]

I quickly read the doc http://doc.akka.io/docs/akka/snapshot/scala/logging.html
We can keep slf4j / log4j outside of rediscala.
And just ajust the level of logging (warn -> info )
What do you think ?
Also I liked warn because you know that you can't access your redis server, so there is something wrong happening somewhere.
But yes if someone just connect the redis client and disconnect it manually, he will get the warning.

[alexanderscott]

Yes, you're right. The Akka logging docs (and Scala logging in general) are a bit confusing - but it shouldn't be necessary to explicitly include the slf4j/log4j stuff, instead deferring to the logging mechanism employed by the consumer client app.

And it's really up to you whether or not to keep that as WARN level or not. I don't see it as WARN appropriate since it reconnects in the same block and it's not uncommon for Redis to cleanup long-lived client connections. But maybe that's just me.

Also quick question - I noticed the closing of the TCP connection takes place inside of the preStart block instead of the postStop block. Does this mean that stopping the RedisClient with context.stop or PoisonPill will not actually cleanup the underlying connection? I created an actor trait RedisDAO with an overridden postStop which explicitly calls RedisClient.stop(), and am wondering if this is even necessary?