logging-log4net-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Drier" <peter.dr...@gmail.com>
Subject Re: Programmatic config and thread safety
Date Tue, 06 Mar 2007 14:53:49 GMT
Hi Brad,

Log4net is definitely thread safe for the logging portion of it's
operations.  I would sync around configuration (and re-configuration)
activities just to be safe, but that would not include log.* calls.

As for using log4net behind an api, keep in mind you'll lose a great deal of
contextual information that you would have had you used log4net natively.
I've been in both situations before (behind an API, and native use of
log4net) and native is hands down better.  The ability to write custom
appenders (for output to anything) and custom plugins (for input from
anything) calls in to question the need for any wrapping.

Some have tried to justify (to me) the wrapping by stating a desire to not
be bound to a particular (external) product.  Logging is such a fundamental
action of development though, that I find that justification BS.  log4net is
so efficient at it's internal processing that there's no reason (I have ever
heard) to replace it for the plumbing purposes of logging.  Sure, life might
change and how much (logging level) or where (appender) the logging goes
might need to change as well, but after 6 or so years of using log4net I
haven't found a requirement or reconfiguration it couldn't handle
without bending
over backwards.

I hope this helps..


p.s.  I'd be up for the debate (off mailing list) for putting it behind an

On 3/5/07, Brad Ivey <bkivey@gmail.com> wrote:
>    I am currently designing the logging componet of a larger software
> project (C#, .NET 2.0, Log4Net 1.2.10).  It's basically a custom logging
> API which uses Log4Net behind the scenes.  The project involves multiple
> processes, some of which have multiple threads.  It is also a requirement
> that all configuration must be done programmatically rather than with a
> config file ( i.e. defining the name of log files at runtime).  We
> initially chose Log4Net because it says right in the FAQ that it's thread
> safe, and I think we just took that at face value.  Once I started digging
> into programmatic configuration API, however, I saw that all the useful
> classes like Hierarchy and Logger, all the Appenders, etc. seem to be
> labelled as NOT thread safe.
>    This leaves me with a few questions that I haven't been able to find
> answers to in the mailing list archives or docs.  First, under what
> circumstances IS Log4Net thread-safe?  My understanding is that it's safe as
> long as I don't directly access classes like Logger in my code and instead
> use the "normal" XML file config methods, is that correct?  And if so, is
> there any reason that I can't just write my own thread sync code around the
> Log4Net calls to ensure that no two threads are making them simultaneously?

View raw message