I'm currently writing a big project in java, with numerous classes, some classes are quiet small, that simply represent objects with only few methods. I have a logger set in my main class, and it works fine. I want to be able to use only one logger (with one console appender) with all the classes. I tried to pass a reference to the logger to the different classes, but it doesn't look right. besides, sometimes I'm running tests on the classes without running main, and thus the logger is not initialized for the other classes.
What's the best approach to accomplish that, I mean, how to log from different classes to one log, with no hard dependency between the classes and with the ability to use the log independently with each class ?
Your logger instances should typically be
private
,static
andfinal
. By doing so, each class will have it's own logger instance (that is created once the class is loaded), so that you could identify the class where the log record was created, and also you no longer need to pass logger instances across classes.The reason you have multiple logger instances is because you want them to behave different when logging (usually by printing out the class name they are configured with). If you do not care about that, you can just create a single static logger instance in a class and use that all over the place.
To create single logger, you can simply create a static utility logging class to be single point logger, so if we need to change the logger package, you will only update this class.
The best way to do it is to have each class have it's own logger (named after the class), then set up your configuration so that they all append to the same appender.
For example:
Then your log4j.properties can look like the example in the log4j documentation:
Both
A
andB
will log to the root logger and hence to the same appender (in this case the console).This will give you what you want: each class is independent but they all write to the same log. You also get the bonus feature that you can change the logging level for each class in the log4j configuration.
As an aside, you might want to consider moving to slf4j if the project is still in early development. slf4j has some enhancements over log4j that make it a little easier to work with.
If I understand correctly, what you have at the minute is:
or, you pass references to a logger into the constructors of the class.
Firstly, you can use one global logger by simply using the same value passed to Logger.getLogger, like:
This uses exactly the same logger, Logger.getLogger returns the same object in both calls. You no longer have a dependency between the classes, and this will work.
The other thing I gather from your comments is that you are configuring by hand (using
BasicConfigurator.configure
. Most of the time this isn't necessary, and you should be doing your configuration by simply adding a log4j.properties or log4j.xml to your classpath. In Eclipse this is done by adding it to src/ (or src/main/resources if you're using maven). If you're using junit, then add it to the test/ source directory (or src/test/resources with maven). This is a much better long term way of configuring log4j, because you don't have to pass information between classes.Also, the recommended way to use loggers is to pass the class to the Logger.getLogger(). In this way you can filter your output based upon the class name, which is usually much more useful than just having one global logger:
Then in the log4j.properties, you can configure a single appender to one file.
Finally, it is not necessary to declare all of your loggers as static. This only makes a noticeable difference if you are doing lots[*] of object creation. Declaring your loggers as non-static fields allows you to use
Logger.getLogger(this.getClass());
in which case adding a logger to a class becomes a cut and paste of a single line. See Should I declare Log references static or not? (unfortunately the link to the wiki page is broken), but the slf4j page contains a good explanation as well. So use non-static fields unless you have a very good reason not to.Cameron is right when he say that you should try and use slf4j if possible, it has one killer feature, you can use multiple logging frameworks with it.
[*] and I mean lots.