What Paul said-- particularly the advise to create two logical kinds of logs (low-level/internal, public-facing)!
-The Wabbit
> The other statement in the same vein is "The most common error in > wrapper classes is the invocation of the Logger.getLogger method on > each log request." Along with the caveat that "This is guaranteed to > wreak havoc on your application's performance. Really!!!" > > What is the preferred alternative to doing that? >
public class MyClass { private static final Logger LOG = Logger.getLogger(MyClass.class); .... }
Then it's available all through your code, and is only initialised once.
> Any pointers would be appreciated. (Note: I've googled, checked the short > manual, the FAQ, the JavaDocs, and the mailing list archives without > success.)
My advice, don't wrap, it's just not worth the hassle, I've created in the past little Util classes that hide log4j from the rest of the app like I am sure so many other people have. Once you get to the point of really needing to know what is going on with a particular class, and can't deal with the volume of logging that tends to happen when an application grows you will thank yourself for having a separate Logger for each class.
Note, you can always do this:
public class MyClass { private static final Logger CLASS_LOG = Logger.getLogger(MyClass.class);
private static final Logger APP_LOG = Logger.getLogger("MyApp.LogicalSystem"); .... }
And then log low-level DEBUGS to the CLASS_LOG, and relevant Application logs to the other logger (logs that have more context with the other logs generated by companion/related components possibly from different packages etc). I am hoping the new 'Domains' concept will help make this a little easier to manage (coming in log4j 1.3).
<aside> Once you begin to use Log4j you will realise how incredibly useful it is, you will really not care about the dependency. You can also later decide to use a pretty easy regexp search/replace to replace 'org.apache.log4j' with the JDK 1.4 Logger equiv (I don't remember what it is, as I've never used it) if you really have issues with the dependency later on.
This is of course 100% IMHO, and I am sure a lot of people starting out with log4j have the same feeling of the need to hide log4j as a component, but with experience I think you will find that having log4j as a friend for each of the classes you develop will pay off handsomely in the end. </aside>
cheers,
Paul Smith
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
