Hello, I am working doing java development - and have had a query as to how to implement logging (using Log4J). My co-worker says we should have singleton/static logging mechanisms the objects call for debug, info, etc.. I wanted to do an abstract class the classes would extend, hence local calls like debud(String, Exception), and info(String) could be called without having to instantiate anything - hence having the logging be almost invisible when writing code. Any thoughts or preferences?
Yes - agreed. As i mentioned above (Log4J), but the question of implementation/abstraction. Should a DAO concerned with data access have to create and/or access a logging object or would that be better suited in a base/abstract class. Rod Johnson's (Spring Framework) "J2ee Design and Development" book at one point suggests that a developer would most likely create a base class to handle the logging aspects - that was my thinking as well. One of my co-workers pointed out (as a good point) - that the base class is now concerned or abstracted for logging functionality and not the business concerns. I was just wondering what the thoughts were of those interested in the forum.
author and iconoclast
I'm sorry -- I've gotten into the bad habit lately of posting answers without carefully reading a post. I need to slow down.
Personally, I think the most important consideration is that it be easy to redirect logging during testing. This means the logger object should come from outside the class, and it should not be hardwired anywhere. Therefore, the DAOs (or any other objects that need logging services) should have a setLogger() method, and store and reuse the logger object they are given. If you need logging utility methods, then I think it's OK to put them in a base class -- along with the setLogger() method.
But having a DAO create its own logger is bad, testing-wise, and separation of concerns-wise. And having static utility methods makes testing DAOs in isolation even harder.