The Avalon project has a Log4j wrapper. See what they did: ttp://tinyurl.com/2yzja
Jake Quoting "Rieser, Michael (SCI TW)" <[EMAIL PROTECTED]>: > > -----Original Message----- > > From: Paul Smith [mailto:[EMAIL PROTECTED] > > > 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); > > .... > > } > > Which is of course the non-wrapped way to use the class. Thanks. I know given > the rest of your response, that you don't feel a wrapper is necessary. But, > I believe since Ceki mentioned it in his article, that there should be a > proper way to write a wrapper, and that is still the information I'm > interested in. I appreciate your response and how quickly you provided it, I > also appreciate the advice your giving about keeping things simple and just > using log4J, but I'm not yet comfortable having everything I'm responsible > for depend directly on Log4J. > > > > > 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. > > Now, this has me thinking we may be on different topics, and perhaps I didn't > make myself clear. I don't have an issue with a logger for each class. I'm > also pretty content with the approach to logging which log4j has taken. So > the paradigm is okay with me, besides Ceki has demonstrated it's very close > to jul. What I'm interested in is creating a single point of package (or > component) dependency such that all the source files I'm responsible for > aren't coupled to log4j (or any particular logger) directly. [Actually I > would have been okay with being coupled to a Java standard logger interface, > but I feel the standard really should have provided an api/spi interface to > logging which would have allowed me to plug log4j in as a service provider > for my logging. Oh well.] Log4J has shown itself mature, stable and feature > rich enough that I'm willing to prefer it even to JDK 1.4 logging, but I'm > not comfortable enough that I want all sources from all projects importing it > directly. > > Anyway, all I'm really attempting at this point is a simple wrapper which > will keep all the projects' sources I'm responsible for dependent on one > "company common" package which is in turn is dependent on Log4J. I thought > such a wrapper shouldn't be too difficult. I'm not interested in > commons-logging nor do I wish to try to re-implement it. > > > > > 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. > > I'm not interested in this for just one project. I have multiple products in > many different java environments (JMX, J2EE (web), Swing, J2SE, and J2EE > (mail)). Since logging is architectually significant in that it touches so > many source files, I am currently more comfortable gating logging through a > common point of contact under company control. I feel if any problems arise > (or a requirement for a different logger), I will have one place to focus on > and change implementation. > > > > > 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> > > I'm sure your right that a lot of people (just starting out) might what a > similiar thing. Maybe it would be reasonable idea then to provide a security > blanket. A simple interface which could be repackaged for a site's own use. > Most of the code I've seen usually just uses Logger.getLogger(MyClass.class) > and the simple methods info(), debug(), etc. I could pretty easily write an > interface with a nested class to implement the factory method. It might be a > little ugly, but it would keep things to one line. > > package com.mycompany.common.logging; > > interface Logger { > void info(Object o); > void debug(Object o); > ... > class Factory { > public Logger getLogger(Object s) { > return LogManager.getLogger(s); > } > } > } > > Usage: > > package com.mycompany.other; > > import com.mycompany.common.logging.Logger; > > class MyClass { > private static final Logger log = Logger.Factory.getLogger(MyClass.class); > > ... > log.debug("just like log4j, which is pretty much plug compatible with jul"); > ... > } > > What I'm missing are the details for writing a wrapper to log4j. In this > simplistic case I could probably just subclass log4j.Logger and implement the > com.mycompany.common.logging.Logger interface. I'm just trying to get a > handle on the issues with wrapping Log4J. I see it has a method already > documented for wrappers > public void log(String callerFQCN, Priority level, Object message, > Throwable t); > > I'm just looking for more info on writing a wrapper. > > > cheers, > > > > Paul Smith > > Thanks again, > Mike Rieser > > --------------------------------------------------------------------- > 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]
