Implement logging framework

[garmu]

Apparently just having logging isn't good enough, we need a framework.

[KatrinaHoffert]

??? We do use a logging framework and logging is used consistently for all server side errors. What more could be needed? On Mar 31, 2015 5:02 PM, "J Lys" notifications@github.com wrote:

Apparently just having logging isn't good enough, we need a framework.

— Reply to this email directly or view it on GitHub https://github.com/MikeHoffert/EatSafe/issues/172.

[garmu]

Ok i just need a short paragraph then of where it is, and what it is doing

[KatrinaHoffert]

Description of logging and its usages:

• Most model functions have the possibility of failing. Most commonly due to database connectivity issues, but also possible if the DB gets out of sync with the code or gets royally fucked up. As a result, these methods wrap the return result in a monad called Try, which will contain the "normal" return value if we found one or the exception that was thrown if a failure occurred.
• At the controller level, we check for the success of our actions. All failures are logged and the user is given an error page. A description string is logged (at the controller level) as well as the stack trace for whatever exception occurred (at the model level). This ensures we can handle errors without the application exiting. Only the most serious errors (eg, out of memory) will crash the application.
• Special handlers like the 404 pages (in Global.scala) log warnings. They do not show an error on our end, but it's useful to know the user does something wrong. Eg, a large number of accesses to a non-existant page may be a sign of trouble.
• Uncaught errors should never happen (their precense means one of us done fucked up), but they're logged by a special global handler, which will display an HTTP 500 page.
• Logging is done through the Play Framework's Logger API. This provides an easy to use, minimalistic logger that helps keep our code clean.
• Configuration of the logging is done in the conf/application.conf file, which allows us to tweak the verbosity of the logging as well as enable logging inside the framework. This unified source of logging is one major reason to use the Play Framework's logging API, as we can keep our logs combined with other Play Framework components.
• The logs are placed in the logs folder. This won't show up in the repo because it's set to be ignored. You'll have to run the app to see the logs. Or check the server's logs.
• On the server, we have separate files for the stdout and stderr. This is handled by nohup. See nohup.out and errors.log in the root directory on the server. These are not used in development, as such text is printed to the console.
• There is no logging of normal visits. This is because Google Analytics (or similar) can do a better job if we merely want to keep track of users visiting pages.

Reopening for Jordan to see. Jordan, close this issue once you've seen this.