logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rieser, Michael \(SCI TW\)" <Michael_Rieser...@stercomm.com>
Subject RE: log4j wrappers
Date Thu, 11 Mar 2004 18:06:33 GMT
> -----Original Message-----
> From: Paul Smith [mailto:paul.smith@lawlex.com.au]
> > 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: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Mime
View raw message