#6 Use a proper logging framework

[Ulf Lorenz]

14th Jan, 2017 -- Iteration 1

1. Add the log4j 2.x libraries
2. Add a configuration file for the setup (to be specified next). It will essentially direct log output to some directory in the deployment folder (bad and will be removed, but reduces setup for the very first iteration).
3. Use log4j in some class. Preferably with the slf4j interface
4. If you feel underemployed, add and use a configuration for the tests that suppresses the log output by default.
5. If there is still time left: Add some skeleton to test logging output in the tests. (For now, I would say, regexp comparison would be enough)
6. Configuration - 1 console appender to capture error/warn and 3 file appenders to log error/info/debug in 3 separate files with appropriate roll over numbers.

---

1. Introduce a better logging framework
   • consider which logging framework to use: slf4j as frontend, but the backend could be log4j, logback, ...
   • include appropriate libraries
   • create configuration file (for appenders to console and rollover file)
   • Server and Client logs should go to the respective output directories in the user home (see ticket [#62]). Implement the functionality speced in ticket [#62].
   • there should be a policy about how/when/how long to retain log files, which is enforced by the code
   • consider having access to the logged output for testing purposes
2. Refactor all existing logging code
   • replace all system.out.print-outs with slf4j logger calls
   • remove obsolete Log class (and refactor to use slf4j)
   • Most relevant for now is the server side
3. Create documentation for proper logger usage
   • how to initialize (private member vs static usage)
   • when to throw a log (avoid log duplication)
   • what to include in the log output (for easier bug analysis and reproduction)
4. add logging to relevant classes for debugging (optional)

[premkumar bhaskal]

Add description for the iteration 1 of the task