----- Original Message -----
From: "Ceki Gülcü" <[EMAIL PROTECTED]>
>I think the logging proposal nicely solves the log4j.jar dependency
>problem. It also offers a simple logging interface but as you will
>soon discover people will want more. They will say, log4j supports
>Nested Diagnostic Contexts, your abstraction does not. Can you please
>add
>that? Oh, by the way, I also like to have Mapped Diagnostic Contexts,
>can you please add that to your abstraction? Sorry, but Mapped
>Diagnostic Contexts require log4j version 1.2. What do you to then?
1000% agree.
I can share my own experience on this one. In my company there has been at a
moment 3 wrappers over different log system. It has been unified to a common
abstraction layer over log4j. A very simple one, and most of all, the
configuration was also a stripped down version (roughly a class list to log,
log level, a log filename).
At that time my opinion was that it was stupid to wrap it because a log
system is so intrusive that you cannot take the full benefit without
exposing it clearly.
Then comes: "Oo I have a problem, my log file is 5GB in 30mins I cannot open
it"... sure...add another configuration entry to allow for a
RollingFileAppender.
Then comes: "Oh, I have a problem, my logs are all mixed, we need a
context". sure... introduce a wrapper over the NDC...
And most of all, since modules were setting their log configuration
themselves instead of a unique log configuration, at the beginning each log
initialization was clearing the whole configuration, it was not adding
appenders but resetting them. A developer was initializing 3 times the log
in the same module !. When we switch to adding appenders...joy.. 3
outputs... a real mess.
At this point there is clearly a big difference about using log4j directly
or not. using it directly would have same us a lot of time and effort !
That's for sure !
>BTW, it is surprising to see logging getting so much attention...
Not so. Very important issue in production to me.
Stephane
