On 5 Dec 06, at 5:26 PM 5 Dec 06, Joakim Erdfelt wrote:
ooh! Logging fight! logging fight! ;-)
(Jason and I argue about this constantly)
Paul Hammant's blog entry - http://paulhammant.com/blog/000241.html
He was railing on about...
* Instantiating logging using IoC techniques.
* Using static logging in a component.
* Logging is mostly never read.
He recommends ...
* Creating a Monitor in your IoC managed component instead of using
static logging.
(Everything from here down is my opinion. so be careful how you
attribute it!)
What he doesn't say ...
* static logging is an anti-pattern.
Yes, he does. Just not in that article.
* using monitor interface in non-components.
Yes, you have to deal with legacy systems but you shouldn't have any
non-components. Even utilities can be instantiated by the container
and managed in the same way.
* Recommends, or makes an attempt to address the use of legacy apis.
For those (thousands) of apis, jars, non-components, etc that already
use logging, we are stuck.
Phoenix and Pico/Nana/MegaContainers all have strategies. Paul works
at Thoughtworks and indeed has to work with plenty of legacy systems.
Again just not in the article. When you do have 5 logging frameworks
you need to unify them certainly. Not everything is component
nirvana, and yes I have actually had to deal with legacy systems.
* Monitor interface proliferation. (static = 1 way to do it,
monitor =
n+1 ways)
Not if you're using more then one static logging framework and a
monitor can still be bound to a single logging framework. In fact, a
whole component hierarchy can even if those components use 5 static
logging frameworks.
* Monitor interface nesting. (a component with a monitor that needs to
use another component with a different monitor)
He's talked about that frequently and that again is not hard when the
monitors are unified to use the underlying logging implementation of
your choice.
* Monitor interface memory issues. (the static logging kings log4j,
jdk-logging, commons-logging, slf4j, etc.. have far far far lower
memory
utilization than using the monitor interface pattern)
How did you arrive at that one? Somewhere in log4j an instance of
something is created to deal with references to calling classes.
* Monitor interface performance. (logging is *very* important,
about as
important as configuration, some organizations prize the log output,
collect it, back it up, aggregate it, send it to data warehouses,
produce reports, evaluation health of app based on logging, etc.
Monitor interface pattern is notoriously bad for performance when
compared to static logging alternatives)
Nothing is stopping them from doing that when you don't use static
logging.
* Monitor interface concurrency issues. (static loggers log4j,
jdk-logging, take great lengths to be thread-safe and support large
volume logging that the monitor interface pattern does not address.)
There are no concurrency issues. Especially when you purely delegate
to the logging implementation of your choice. It's an interface, so
you would only end up with concurrency issues if the logging
implementation has issues.
- commons-logging -
commons-logging has been pegged with ClassLoader issues for a long
time.
Fact is, commons-logging has been a victim of a horrendously bad
Exception message.
An exception message that was expanded and corrected in commons-
logging
1.0.4.
The true nature of the perceived "ClassLoader" issues are revealed in
all their glory starting with 1.0.4.
commons-logging 1.1 introduced a more comprehensive set of checks and
exceptions to help you identify the root cause of most of the
commons-logging headaches (configuration!, not classloader, not
classpath, not even the commons-logging.jar vs commons-logging-api.jar
debate.)
- Suggestion: slf4j & plexus -
We should rip out all of commons-logging & log4j & jdk-logging efforts
within plexus.
We should write all of our logging against slf4j.
-1
Absolutely not. sl4j can certainly be the default implementation but
Plexus will not be bound a logging framework. Plexus' logging
interface is not a framework.
Then we can stop bickering about logging. let slf4j deal with the
configuration of the other loggers in a real-world application (like
maven and archiva) which inevitably use all 4 logging APIs AT THE
SAME TIME.
+1 for that being the default but there isn't a chance it will be
wired into Plexus itself. Even if it works from J2ME to J2EE if
someone wanted to unhinged and make a specialized logging
implementation it means they could do that directly and not have to
worry about being hinged. Being bound to sl4j is just as bad as being
bound to commons-logging, it's just sl4j is a better implementation.
Jason.
- Joakim
Jason van Zyl wrote:
On 5 Dec 06, at 12:23 PM 5 Dec 06, Henri Yandell wrote:
On 12/3/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:
On 3 Dec 06, at 11:29 PM 3 Dec 06, Carlos Sanchez wrote:
I think something like http://www.slf4j.org/ can allow using
libraries
that use commons-logging without getting its problems
I didn't see it in there anyway, but the problem is not only that
commons-logging is a piece of crap
My understanding is that the classloader issues have been worked out
in the 1.1 release.
Classloader issues aside it's still a piece of crap. Static
logging is
bad and is an anti-pattern for component-based programming. Causes
nothing but grief. I know you can use commons-logging as a monitor
but
no one does that. Paul Hammant's blog on why static logging is
crap is
a good read.
, but that people also abuse it and
put logging in libraries when they should be throwing exceptions
and
be tested properly so you know what it does and so you don't
have to
stick logging in a library which is just plain dumb.
DBCP and FileUpload are two where I can see that I would want to
log,
but for most libraries I don't see the need. IO and Lang (two I've
introduced so far) don't use logging.
You want to test, have a monitor or eventing system so that you can
get anything important to go to a console, some form or GUI, or a log
file if you like. Going straight to logging is the extremely limited
and makes integration a pain in the ass.
Hen
