Java Logging With Abstract Classes

Question

I am working on a project, and am currently working on implementing some logging with log4j and I was curious about how I should go about implementing the logs. The two implemen

Answer 1

The same can be achieved by playing with constructors. Add logger at the Base class level and set it from every Derived class using super(). There is the code :

public abstract class AbstractFoo {

    protected Log log;  // base abstract class has a Log object.

    public AbstractFoo(Log logger) {   // parameterized constructor for logger, to be used by the derived class.
        this.log = logger;
    }

    public doSomething() {        // common method for all the derived classes.
      log.info("log something");
    }
    // rest of business logic.
}

public class Foo extends AbstractFoo {

    public Foo(){
        super(LogFactory.getLog(AbstractFoo.class));
    }

    public void someMethod() {
        log.info("Using own log");     // this uses its own logger.
    }
}

Answer 2

There are 2 reasons (that I can think of) for having a Logger in the abstract class:

1. Usage of the logger in a method of the abstract class, while still logging out the concrete class as the caller.
2. Unified logging or common logging among all concrete classes.

If you prefer static loggers (that's my preferred choice too), then n1cr4m's answer solves #1 and #2 very well.

However, if you're more interested in #2 and dislike the fact, that each concrete class needs to implement getLogger(), then you could do the following. As an example I'll use a converter:

public abstract class AbstractConverter{

   protected void logError(Logger logger, String someId, String msg){
       logger.error("Error during conversion of unit \""+ someId + "\": " + msg); 
   }

}

The logger can be a static logger from a concrete class. Now anytime you log, you will uniformally print the prefix, which also forces the identification of the object it converts.

The drawback of this solution, is that if AbstractConverter needs to use the logger himself in one of its methods, it wont be able to use the logger from the concrete class, unless you also make this a parameter, which I highly discourage. If you need this kind of functionality, use n1cr4m's solution.

Answer 3

Both make sense. It depends on your application.

I think that more often used practice is to have private logger for each class. This allows you to configure logging both per class and per package. Remember, that AbstractFoo and Foo may belong to different packages and probably you want to see logs from Foo only.

Moreover always think twice if you want to write protected field. It is not completely forbidden but a well known bad practice. It makes your code less readable and difficult to maintain.

Answer 4

I wouldn't do either. Instead I would make it use the correct class in both cases.

public abstract class AbstractFoo {
    protected final Log log = LogFactory.getLog(getClass());

    ...
}

public class Foo extends AbstractFoo {
    public void someMethod() {
        log.info("Using abstract log");
    }
}

If you are not doing lots of logging (which is a good idea anyway) you can use a method instead.

public abstract class AbstractFoo {
    protected Log log() { return LogFactory.getLog(getClass()); }

    ...
}

If there is a class which calls this a lot you can override it to give you a cached instance.

Answer 5

This is my solution (final static logger):

public abstract class AbstractFoo {
     protected abstract Log getLogger();
     public doSomething() {
          getLogger().info("log something");
     }
}

public class Foo extends AbstractFoo {
    private static final Log log = Log.getLogger(Foo.class);

    protected Log getLogger() {
         return log;
    }
    public doSomethingElse() {
          log.info("log somethingElse");
    }
}

Answer 6

If you create the logger in the abstract class, the logs will all come out tagged as originating from AbstractFoo. If you want/need to see logs tagged with the child class from which the log occurred, create loggers for the children classes.