What makes jLo different

Logging is a crucial part of every application. Using a bad logging framework or even worse System.out.println can decrease the performance of your application dramatically. If your application is running day and night a log file is always helpful to see what is going on, especially when there are errors.

There are quite a number of logging frameworks currently available so what was the motivation behind building yet another one. Here are a few things that we have not found in another other frameworks and we think that these features are quite important.

It was not our intention to just build another logging framework. We started the development of this software a few years ago and since then jLo has been used in a number of huge projects and has written countless lines of log messages. For us this tool is always the first choice when it comes to logging.

Levels and targets

Most of the logging frameworks in Java use the term of levels. This means that every logger has a defined level which is the threshold where the logger will actually start writing out the log message. There are also hierarchies defined for such levels such as INFO, DEBUG or FATAL or whatever. If you define the level to the lowest level then all log messages are written out. Somehow this principle was introduced within Java due to frameworks like log4j or the JDK logging. If you look at other logging framework like the syslog under Linux there is a huge difference. There are no levels used. Rather than defining level you can switch on and off every level. It is more like a bitset where you can define what a logger should write out and nothing more. Filtering all INFO and FATAL messages should be a possibility from a logging framework. jLo picks up this idea and introduces targets. These are independent levels that can be switched on and off separately.

Getting further

If you take the idea of having independent targets for every logger that can be separately switched on and off, you can expand upon this and take the next logical step. Defining a good logging strategy within a huge application can be very helpful. With other frameworks you can only choose the defined levels. Define a rule like "the first thing in every method should be a log output writing out the parameters passed to the method". Since this information is not so important, you would use INFO. Now to see these messages you need to define INFO as level for the loggers. This would write out every log request which leads to a heavy log file where you can only hardly find your information.
It would be better if you could define a new target like ENTERING. Then you could use this target when entering a method. You could also enable this target and say that you want to have for example all ENTERING and FATAL targets but nothing else. Another example would be to define a target SQL where you write out the SQL statements and then enable the target in case you need to trace a problem with your SQL statements. jLo supports this by introducing a code generator that lets you build your own logging framework with your defined targets. Rather than supporting a way of having user defined targets by supporting something like:

logger.log("sql","insert into ....");

we believe that is better to have strong typing like:

logger.sql("insert into ......");

Having this ability you can now start to define your logging strategy and implement it by building your own jLo version. Since we cannot know what you might need as targets, it doesn't make sense to define so many targets to try to fit your needs. The better approach is to do