At 10:10 27/3/01 +0200, Leo Simons wrote:
>I think multiple.
>1) The most common case is that you want to store the log
>messages in some kind of repository (ie textfile), AND notify the sys admin
>in case of problems needing immediate attention.
>2) I imagine an avalon installation running many sars. For each sar,
>warnings and errors are logged separately. But it seems likely you'd
>also want errors from one sar that may affect another (which will
>probably happen somewhere) logged in an avalon log file.
>3) not to mention complicated distributen multi-server envs - which
>usually need the speed.
sounds reasonable. In Avalon/Phoenixs case multi is definetly going to be
the norm.
>MORE ON LOGGING
>---------------
>I believe I said I would be looking into logging stuff, and I'm on that
>at the moment. There's only one big issue:
>
>jakarta's got both Log4J and Avalon's LogKit.
>
>I believe it is important to decide _now_ how to resolve this. Options:
>
>1 - merge logkit into log4j.
>2 - make logkit wrap around log4j (so log4j can be used in 3.1~ avalon).
>3 - in avalon 4 (or whatever it should be called), remove logkit in
> favor of log4j.
>4 - don't resolve; keep the separation forever.
>
>2 & 3 could both be done, but that'd be imo, a waste of time.
>I think option 3 is the best (based on my reading of e-mail archives).
>However, there might be advantages to logkit that log4j doesn't have.
>Could someone (Peter ;-) enlighten me here?
speed, design, stability
speed - Logkit was considerably faster than log4j last time I checked.
Important for me because usually I place logging statements every few lines
because there has never been a debugger good-enough for me ;)
design - logkit was essentially started because I didn't like design of
log4j (This was ages ago). It is overly complex and has a poor conceptual
model. (ie why log to category rather than to a logger about a category).
It also integrates a lot of other things that aren't really needed in a
logging framework (internationalisation, transformation of objects to
strings).
stability - logkit is much more stable. It has seen very few changes since
I originally built it (besides a few cosmetic ones like moving it to
org.apache.log.*). I have wanted to rip out ContextStack for ages but
haven't because I want to keep it stable.
It would be nice if it were merged but Ceki indicated that would not happen
;) (Or at least not in a way suitable to me). We could maybe add the
concept of Appenders into Logkit and share appenders between the projects
but other that I can't see the design goals of both toolkits being "merged".
There is one thing that has been on my TODO for aaaaaaaages (I may check it
in tonight) is adding
is<Priority>Enabled()
So you could go something like
if( getLogger().isWarnEnabled() )
{
getLogger().warn( "Some " + " expensive " + "string" + "operation" );
}
I believe log4j has something similar.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
