> > The one thing that we did abstract for log4j client code is the > acquisition > of the Logger instance (see below). Despite the advice to the contrary > we > found that we needed at least thread-specific logging control in some > circumstances, so storing the Logger instance in a static or instance > variable can restrict the use of your classes if you confront this > requirement.
HeHe - actually, I also 100% agree with this approach! I didn't mention it, but we did this also - wasn't really sure it counted as wrappering, since all the interfaces used remained the same, just how to get a Logger instance. We buried ours inside a OSGi Log service, which lets us create/control multiple hiearchies to isolate logging for different services. Once we've got a Logger though, we just use the standard LOG4J API's -- Rob SoftSell Business Systems, Ltd. ' testing solutions for a changing world ' +44 (20) 7488 3470 www.softsell.com [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>