Logging Improvements

[tpickett66]

Perhaps we should move away from the global $LOG and to something that self initializes to a null logger if one isn't configured. Maybe, we could also set it up so we can simply call logger.warn to put out a message. If we do this last bit or not doesn't really matter but we need to stop polluting our test output with log messages going to STDOUT.

Also, perhaps we can also use one of the more advanced logging gems (log4r or logging) so we can have more precise control over what gets logged. The real advantage here would be that you can tune the logging level of various classes/namespaces without changing them all.

[mitfik]

You can decrees number of log messages by setting ERROR level.
Of course it will be good to implement possibility to point logger to a file not just STDOUT.

Also I agree that we could improve that (global variables are not best practice) but for know I think this one do not have high priority.

Regarding additional gems I would like to avoid adding something which will not provide any additional value. I know that logging is very important but in most cases Logger class from ruby core can do the job. Those gems can do some magic staff but do we really need that in such simple app?

This what I suggest:

• implement logger object which will replace $LOG
• add possibility to set output for logger

[tpickett66]

I understand how to manipulate the logger into being less chatty in test, I just noticed a deficiency in our current process and thought I would get some discussion started. As for external gems for logging, they don't provide any magic but they do bring two very useful features to the party:

1. Namespaced logging, this allows us to set the logging level of various modules independently enabling faster debugging by not having to sift through nearly as much data to find the relevant parts.
2. Output to multiple streams at once. I know we can easily put this together for ruby's built in logger but that's more infrastructure to maintain that has nothing to do with our problem and as much as I hate dependencies I hate duplicating functionality.

I agree that our current t needs don't warrant anything more complex, fortunately the logging gem's base API is completely compatible with the built in one so when we change our minds we can change our code easily.

[mitfik]

I do not mind to use those gems I just would like to know why. I am fine with that what we have right now it covers all my needs, this is why I do not see any additional value by adding those gems.
Maybe if you could provide answers (examples of use, use case), it will be easier for me to understand why:

1. Why do we want to have namespaced logging, how it will improve our life (development), user life (production)?
2. Multiple streams sound great for something huge here we have simple functionality where logging is quite small compare to other big projects. Do you have any specific scenario where you want to use that? One file for each level? What if we would like to see step by step what happened in our app, in one file is quite easy to see the timeline, in many streams you are loosing overview of that what exactly happened and in which order.

I will be glad if you could provide my some examples how we could benefit from those features.
Thanks

[tpickett66]

Multiple output streams isn't really necessary until you have very large deployments but the name spaced logging is quite useful. For example (totally contrived but illustrative): Say I have a custom ticket validation process that checks several parameters on the tickets and some web API I have set up so I can tune these things on the fly but I'm having trouble with the parameter checking and can't identify it in testing. As things sit if I want to see real logging coming out of this single class at the DEBUG level in production I have to set the whole app to DEBUG. This would lead to very large log files that would be essentially useless for debugging purposes without writing a log evaluation tool for this single scenario. Now consider if I could just set that class to DEBUG and leave the rest of the app at WARN or ERROR I would have a reasonable log file I could parse by hand or off the shelf tools quickly to see where the breakdown is occurring.

[mitfik]

Thanks a lot for that example.
Now I see that this feature could be helpful indeed. We could considering evaluation of existing plugins under name spaced logging feature. Also we could consider to have some simple implementation base on top of existing Logging class from ruby core. Everything depends on which one will be better and simpler to maintain for us.