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.. Cheers, Peter p.s. I'd be up for the debate (off mailing list) for putting it behind an API. On 3/5/07, Brad Ivey <[EMAIL PROTECTED]> 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?
