Remove the log4j dependency

[GoogleCodeExporter]

Keyczar is hard to embed in applications because it forces a dependency with 
log4j. This has several implications:

* The performance and extensibility of log4j has been discussed in comparison 
with other alternatives like logback (also by Ceki Gülkü)
* This library forces a new dependency. This is a problem when the developer 
wants to use another logging framework, for example JUL included in the JDK 
(which is something that AppEngine promotes strongly).

A solution would be to migrate from log4j to slf4j. This does not break 
backwards compatibility since slf4j has modules to detect automatically JUL, 
logback and log4j, and can also behave well with commons-logging, is that's the 
case. It's more or less the accepted logging adapter layer these days.

Please notice that this is only a requirement to be able to embed Keyczar in 
third-party applications, where forcing a concrete logging framework is not 
really an option. 

Original issue reported on code.google.com by icol...@gmail.com on 5 Jan 2013 at 12:55

[GoogleCodeExporter]

Original comment by jtu...@gmail.com on 2 Mar 2013 at 9:08

• Added labels: Maintainability, Implementation-Java

[GoogleCodeExporter]

Original comment by jtu...@gmail.com on 2 Mar 2013 at 9:09

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Not sure if googlecode has pull requests like github does, but here's a commit 
for this

https://code.google.com/r/benjaminjmccann-keyczar/source/detail?r=151f651cf8164c
87a34e5abd4facb50d21a11c0a&name=slf4j

Original comment by benjamin...@gmail.com on 10 Nov 2013 at 2:25

[GoogleCodeExporter]

I made some changes to support this as well.  
https://code.google.com/r/giladamcom-keyczar/source/browse?name=java-slf4j-loggi
ng

I think I covered the tests, too, by providing logback and a similar 
configuration but it's only a testing dependency and not a compile one.

Original comment by giladam...@gmail.com on 26 Feb 2014 at 6:46