Why we should consider the «Logger» class as a singleton?

Question

We all know about log, ok, but why should we consider the «Logger» class a singleton one? What happens if we make it as a normal non-singleton class?

Answer 1

I found this here on the IBM site. It explains the usage of a Logger Singleton class quite well.

A classic example of a true singleton is a logging service. Suppose we have an event-based logging service: Client objects request that text be logged by sending a message to the logging service. Other objects actually log the text somewhere (console, file, whatever) by listening to the logging service for these logging requests and handling them. First, notice that the logging service passes the classic test for being a singleton:

• The requesters need a well-known object to which to send requests to log. This means a global point of access.
• Since the logging service is a single event source to which multiple listeners can register, there only needs to be one instance.

Here the link: Use your singletons wisely

If you wouldn't use a singleton class you would have to deal with the synchronisation (writing to a file, or whatever stream you use) between these different logger instances. So its much easier, when you just have one global Logger instance.

Answer 2

The main problem is where the actual log is persisted.

If you are writing on a filesystem, having more than one instance (and therefore, probably, more than one thread) may result in a garbled file.

In the sense that depending on buffering and other low-level mechanisms messages from one write may end up mixed with messages (or parts of messages) from others.

This may be a minor problem, but it's the only one I can think of regarding having just one (and therefore serial) log writing object.