Go read this: http://www.qos.ch/logging/thinkAgain.html
(In particular the links half way down).

Basically, the commons-logging class discovery isn’t as clever as the JBoss/Tomcat/ classloaders, resulting in ClassNotFound exceptions all over the shop.

If you’re going to tie someone to using commons-logging, you may as well tie them to using log4j, which at least actually *works*, without needing you to get your head around the interactions between three different classloaders.

“Why not use clogging and pass the output to log4j which then sends it on to the JDK logger which uses callbacks to log4j to format the output and then gets clogging to throw exceptions for the JVM to catch and pass to the original app so that it can then log it via clogging……”

To be honest, I don’t see why logging is needed for anyone but the developers. The version that is released should not contain logging, it should be removed from the development version at release time.

If only the developers need it, they can use whatever system they want. It won’t matter as it won’t get near the users. The only time users should have logging is if the developers are the users, or if the users goto CVS and become developers.

On the other hand, if you’re a dimwit fapping to commons-*, you pick commons-*, rant and rave about how good it is, invent/embrace their marketing mantras such as pluggable logging and smile at the people you think are laughing with you.

By using the same logging implementation you have one configuration for all the code.

Where is the problem with the above statement? Do you have another solution?

Please read and THINK before you answer…

jw wrote:

“I think that commons-logging is necessary for open source projects that want to use logging and they don’t want to enforce their users to use a particular logging implementation.”

commons-logging _is_ a logging implementation and a dependency you idiot!

What a wreckless piece of null bucket code OSworkflow is. We tried using it for a year after our own guys added to their bad design by writing equally dumb code. Anyone who uses OSworkflow could do themselves a flavor and write then own stuff. That’s what we had to do. Their serialization model sux. It’s so general purpose that its good for nada.

Yeah, yeah, licensing, licensing, licensing.

Whatever.

At work we abandoned all direct use of clogging, and use Log4j directly, because we want to use it’s advanced features that clogging doesn’t support, and also because we realized the sillyness of not just sticking with a specific logger…

How exactly do you propose tools/libraries that are intended for use in larger application (e.g. OSWorkflow) handle their logging?

For fucks sake get a life - it’s just logging, not a cure for cancer.

Give me System.out or give me death…

If you choose that the output should contain classnames or linenumbers, exceptions wille be generated. Actually the javadocs of log4j are warning against the performanceiomplications of using classnames or linenumbers.

A good alternative is instead to output the name of the logger (which almost always is the same as the classname)

Note: there is no other way of specifying this information (short of including it verbatim in the log call, which can be done through the Logger.logrb() method for example). If log4j doesn’t do this, then it means that log4j cannot include the name of the calling method in the log messages and therefore it sucks.

So, there are two ways of getting rid of the creation of the Throwable: 1) Don’t include the calling class or method in the output or 2) include that information yourself in the call to the log method when you log performance sensitive sections of the code.

Is there a better way to do it?

If you use ‘commons’ it means you are using basic API calls and it’s a breeze to change from one API to another via search/replace in your IDE or a hand crafted shell/python/perl (or a Ant replaceregexp filter if you’re not comfortable with the later scripts language)

Switch at runtime ? yeah right. How cool is it to switch your logging package ? Frankly that’s useless.

Why ? Well, in most case you can get the most of a logging package by using its features, should it be NDC or specific appenders you won’t find anywhere else. In that case you’re tied to the API anyway. So stick with it.

Use log4j and stick to it. Period.