Re: Aspect questions?

On 2/25/2012 3:22 PM, Arne Vajh?j wrote:


I can think of a use case for it though. Let's say you haven't decided
which logging framework to use, or you want to be flexible as to which
one to use. (Different customers of yours prefer different loggers.)

(Not syntax checked or tested.)

abstract class MyLogger {

   public static MyLogger getLogger( String name ) {
      MyLogger logger = Class.forName(
               System.getProperty("me.mystuff.MyLogger.logImpl",
                       "me.mystuff.MyDefaultLogger" ).newInstance());
      return logger;
   }

   public abstract void logStuff(Object...);
}

So the idea is that you wrap the logging framework in your own, and then
you're free to provide an implementation that matches whatever logging
framework you choose to use in the future. Maybe this is not for
everyone, but I could see its advantages. Some folks might like
java.util.Logger, some folks like log4j. And some might like things
that I don't know about yet.

A couple of other things.

Lew wrote:

  public class Foo
  {
    final Logger logger = getLogger(getClass());
[...]
   }

This requires that a logger is instantiated for each object as it is
created. Potentially this is a lot of work, and each logger may not be
used. (Even declaring the logger to be static still requires a logger
per class loaded.)

Whereas this:

   ...
   try {
     ... some stuff...
   } catch (Exception ex) {
     getLogger(getClass()).log( ... );
   }

creates the logger lazily and therefore doesn't spend any resources if
logging happens to be never required.

Lastly, I don't know about log4j, but I don't think the
java.util.logging package uses threads when logging. Any IO operations
the logger makes will block the calling thread. I've heard this is
undesirable in most cases. So rolling your own framework also gives you
control over threading issues too, which again might be important for
some customers.