Java – Best Design Pattern for Logging

design-patternsjavaloggingobserver-pattern

I should log some events in a program but as far as I know it would be better to keep the logging code outside the program because it is not about the real functionality of the program. So may you tell me if I should keep it completely out of code and only use Observers and Listeners to log the events? Or I can add a line of code like the following wherever I need to log something:

MyGloriousLogger.getXXXLogger().Log(LogPlace, new LogObject(z1, z2, z3, z4, ..., z99));

Do I make a mistake to use Observer design pattern? I need another design pattern? Or I should stop thinking about design patterns?

PS1. If I want to log using only listeners and observers I will certainly need to add and improve the observers and listeners of the program.

PS2. I certainly know that there are different libraries for logging in Java and I'm using java.utils.logging but I need to have a wrapper for it to log my special objects.

Best Answer

Logging is usually implemented with the Chain of responsibility pattern. Of course you can (and I would) combine that with a Facade. I really wouldn't use Listener(s) or Observer(s) myself.

Chain of responsibility - Logger

Related Solutions

Java Logging – Rules and Advice for Effective Logging

As an extension of your rule of logging where in the application the log statement came from, you may want to add per module level logging flags. Instead of logging everything, all the time, this allows you to selectively target sections of your application instead. There is overhead in this, and you need to create a facility that allows you to enable / disable that logging. Ideally, you would be able to enable / disable on-the-fly as the application is running.

I'm used to seeing a layer below debug which I term "Trace", but that's not necessarily a universal term. "Trace" level logging tracks as much as you can possibly stand, including module entry / exit, timestamps with entry / exit, and bonus points for capturing passed values. Obviously, that generates a LOT of data and it's not something you turn on willy-nilly. But it has advantages with respect to debugging when you can't attach to the process or you don't have a core dump of the errant application.

I like to see file / module references and timestamps with my log information. It can be handy when trying to hunt down race conditions between threads as well as coordinating the activities of multiple areas of the application. To be fair, I know of some folk who think these details clutter the log file. Adding in the timestamp is something to discuss with the team. (Apologies if log4j already does that.)

If the logging isn't being taken care of by it's own thread / process, that's something to consider as well. Instead of making the application thread wait for the logging to process, the log message gets passed off to the log handler and the application thread goes on its merry way. Alternatively, creating some sort of buffer mechanism to handle the log messages is another way to speed up application responsiveness.

Having controls on the size and history of log files is another feature to consider. You don't want the app blowing out all the disk space on the host system, nor do you necessarily want to keep all log files for all eternity.

Design pattern for chained observers

That's called Reactive Programming.

Look at Rx.

Rx is all about this.

It treats observables as enumerables and then what you are doing becomes as simple as calling map on the first sequence of events.

 events.map(new function(each) { return override != null ? override : each }

Rx is available for many languages, you'll find a video with an introduction of RxJS for Javascript here, http://youtu.be/FqBq4uoiG0M

Best Answer

Related Solutions

Java Logging – Rules and Advice for Effective Logging

Design pattern for chained observers

Related Topic