POSper / Patches / #3 'slf4j + logback' replacing 'log4j' as logging framework.

Pedro Romano - 2007-09-11

'slf4j + posper' replacing 'log4j' patch.

posper-devel-r332-slf4j-logback.patch

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Aaron Luchko - 2007-10-02

assigned_to: nobody --> aluchko
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Aaron Luchko - 2007-10-02

Logged In: YES
user_id=1537379
Originator: NO

Sorry for not responding earlier, I didn't actually know we had anything in the patch tracker (the bug tracker is set to notify devel list but not the patch tracker apparently).

I'll take a look at this patch.

thanks,
Aaron

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Pedro Romano - 2007-10-02

Logged In: YES
user_id=1208009
Originator: YES

No problem. If you like it, I'll update it to the latest revision if necessary, and then would like to do some janitorial work and convert all 'System.[err|out].print[ln]'s and 'printStackTrace's to logger calls.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Aaron Luchko - 2007-10-02

Logged In: YES
user_id=1537379
Originator: NO

That would be great though I should probably take a quick look at the patch as it is before you do any further work just to make sure the approach will work for us.

thanks,
Aaron

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Aaron Luchko - 2007-10-10

Logged In: YES
user_id=1537379
Originator: NO

Hi Pedro,

The code looks good though I'd still like to get a better idea of the benefits. The only real difference in general usage I can really see from the patch is XML instead of properties files? As for the benefits from what I can tell is slf4j works as an abstraction layer so if we have some library using a different logging framework we can still interact with it?

There are also a couple concerns I have, one is

- hibLogger.setLevel(Level.FATAL);
+ hibLogger.setLevel(Level.ERROR);

For us there is a difference between FATAL and ERROR. Essentially there are a couple cases where we're testing some property with the DB or our connection and the only way to do so results in a hibernate reporting an ERROR. Since we don't want the user confused by an expected, and fixed, error we hide it. I haven't had a chance to run the code but if this does cause those ERRORs to become visible we'll need someway to hide them, preferably without turning off logging altogether (though we're pretty much doing that already). Really the current code should only be setting the level to FATAL for the hibernate logger and the new code would ideally do the same but the errors in those sections being visible would be a regression that would have to be fixed.

There are a couple other bits I'm wondering about

"Operations such as configuring appenders or setting logging levels cannot be performed with SLF4J. Thus, at some point in time, any non-trivial application will need to directly invoke the underlying logging system."

"For example, direct references to log4j appenders, filters or PropertyConfigurator are not supported by log4j-over-slf4j."

One of our plans is to eventually replace a lot of the error dialogs with Appenders that report as dialogs, will this still be simple with slf4j it sounds like we'll need log4j somewhere at least to create the appenders?

I'm still unsure about this since we're introducing some new dependencies and complications and I'm not quite sure what benefits it brings us yet. The only thing I can really think of is if we end up using a library that uses a different logging framework and we want to interface, however we don't have anything like that currently if it is mostly 1 line changes we might be able to make the update when the time comes with a find/replace.

p.s.
I somehow missed the bit you wrote about Logback :) I'll have a look at that to see what it would buy us over log4j though if it does have some improvements for us it may render a bunch of my comment obsolete.

thanks,
Aaron

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Pedro Romano - 2007-10-10

Logged In: YES
user_id=1208009
Originator: YES

Hi Aaron,

I really hope you have the opportunity to checkout the 'logback' and 'slf4j' sites, FAQs, and other assorted information. I think you'll be convinced of the merits of this solution.

'slf4j' makes lots of sense for a library, where you don't want to impose a logging framework on the user. Apache Jakarta Commons Logging (JCL) is the original (and legacy) solution for this problem. However, the serious problems JCL has, have motivated the appearance of 'slf4j'.

For POSper, as a whole solution, maybe using 'slf4j' doesn't make sense, and just using 'logback' directly is the best solution. The added value of 'slf4j' is really the ability to very easily switch the logging framework. If this is not, and does not look like it will ever be an issue for POSper, than it may be best if it is skipped.

The real issue here is 'log4j' vs. 'logback'. From the 'logback' frontpage:

"Logback is intended as a successor to the popular log4j project. It was designed by Ceki Gülcü, the founder of log4j. It builds upon experience gained in building industrial-strength logging systems going back as far as 1999.

(...) The logback-classic module can be assimilated to a significantly improved version of log4j. Moreover, logback-classic natively implements the SLF4J API so that you can readily switch back and forth between logback and other logging systems such as log4j or JDK14 Logging."

'Hibernate' for example (and several other high profile projects) is using 'logback'.

Checking out the 'logback' website (http://logback.qos.ch/) should convince you.

Direct link to presentation 'Top 10 reasons for migrating to logback, by Ceki Gülcü and Sébastien Pennec': http://logback.qos.ch/10reasons.ppt

The reason for the missing 'Level.FATAL' in 'logback' (and 'slf4j' which is the interface it implements) is explained by its authors this way (from the 'slf4j' FAQ):

"Why doesn't the org.slf4j.Logger interface have methods for the FATAL level?

From the stand point of a logging system, the distinction between a fatal error and an error is usually not very useful. Most programmers exit the application when a fatal error is encountered. However, a logging library cannot (and should not) decide on its own to terminate an application. The initiative to exit the application must be left to the developer.

Thus, the most the FATAL level can do is to highlight a given error as the cause for application to crash. However, errors are by definition exceptional events that merit attention. If a given situation causes errors to be logged, the causes should be attended to as soon as possible. However, if the "error" is actually a normal situation which cannot be prevented but merits being aware of, then it should be marked as WARN, not ERROR.

Assuming the ERROR level designates exceptional situations meriting close attention, we are inclined to believe that the FATAL level is superfluous."

However 'logback' (by implementing the 'slf4j' interface) implements the concept of 'Marker' which may be used to overcome the absence of the FATAL level: for example, when mapping from 'log4j' to 'slf4j', log4j's fatal() printing method is mapped to logback's error() method with a FATAL marker.

So, I really hope the the absence of 'Level.FATAL' is not a show stopper!

I am ready to update the patch to 'devel' branch head, either by using 'slf4j' + 'logback', or a direct 'logback' solution. I will substitute 'Level.FATAL' by a 'Level.ERROR' + 'FATAL' marker.

Looking forward to your feedback. Thanks.

Best regards,
--Pedro.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Aaron Luchko - 2007-10-10

Logged In: YES
user_id=1537379
Originator: NO

>For POSper, as a whole solution, maybe using 'slf4j' doesn't make sense,
>and just using 'logback' directly is the best solution. The added value of
>'slf4j' is really the ability to very easily switch the logging framework.
>If this is not, and does not look like it will ever be an issue for POSper,
>than it may be best if it is skipped.

>The real issue here is 'log4j' vs. 'logback'. From the 'logback'
>frontpage:

If we switch to logback would we still be able to easily manipulate hibernate's log4j logging without slf4j?

>'Hibernate' for example (and several other high profile projects) is using
>'logback'.

I'm guessing this is a yes to my former question then?

>"Why doesn't the org.slf4j.Logger interface have methods for the FATAL
>level?

>So, I really hope the the absence of 'Level.FATAL' is not a show stopper!

Yeah I read up on this and I understand why, it's just a potential problem for us since we are expecting those hibernate errors. The problem isn't so much the difference between FATAL and ERROR but the ability to stop hibernate from logging those errors in those two sections, and if hibernate is using logback and the log4j stuff is just a wrapper or something than they may not be using FATAL at all so in that case there wouldn't be any difference in setting Level.FATAL or turning off logging for that section entirely.

So the absence of Level.FATAL is a show stopper iff there's no other way to stop hibernate from reporting errors for those two sections since those errors were the source of a number people reporting errors.

>I am ready to update the patch to 'devel' branch head, either by using
>'slf4j' + 'logback', or a direct 'logback' solution. I will substitute
>'Level.FATAL' by a 'Level.ERROR' + 'FATAL' marker.

Particularly if hibernate is already using logback I'm definitely open to switching to that. I'm still a bit unsure about the slf4j if it isn't buying us any benefit, I don't see POSper being used as a library, the only comparable scenario is future plug-in support but I suspect plug-ins would have to be custom written so they'd probably just use our logging framework as well.

thanks,
Aaron

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Pedro Romano - 2007-10-10

Logged In: YES
user_id=1208009
Originator: YES

I'll update the patch to only use 'logback' while keeping the current intended behaviour of masking the expected Hibernate errors, and keeping in mind your other comments. You can then review and comment it again. Thanks!
--Pedro.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Aaron Luchko - 2007-10-15

Logged In: YES
user_id=1537379
Originator: NO

I've read through a bunch of the logback manual and it looks great, if you update the patch as described (hiding the hibernate errors and such) I'll be more than happy to apply it!

thanks,
Aaron

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Pedro Romano - 2007-10-16

Logged In: YES
user_id=1208009
Originator: YES

Hi Aaron,

Really glad you liked what migrating to logback has to offer!

I am working on the updated patch, keeping in mind the project´s requirements. Hope to send it today or tomorrow. Thanks.

Regards,
--Pedro.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Aaron Luchko - 2007-12-05

Logged In: YES
user_id=1537379
Originator: NO

Hey Pedro,

I was wondering if you were still working on this patch?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

'slf4j + logback' replacing 'log4j' as logging framework.

Get the new release!

Group

Searches

Help

#3 'slf4j + logback' replacing 'log4j' as logging framework.

Discussion