package somepackage;Thoughts?
import java.util.logging.Logger;
/**
* Self maintaining package level logger access
*
*/
final class Log {
private static Logger logger;
// not thread safe
static Logger getLogger() {
if (logger == null) {
logger =
Logger.getLogger(Log.class.getPackage().getName());
}
return logger;
}
private Log(){}
}
Friday, August 29, 2008
Self maintaining package level logger access class
Many times I have seen that programmers declare a static field which hold an instance of a Logger. I find this pattern repeated in many classes in the same package. Below is an example of a simple package level logger accessor class. It has an interesting property being a self maintaining code in that you can drop this code in any package and fix the package name by hand or even better let the IDE such as Eclipse provide the quick fix to correct the package for you.
Subscribe to:
Post Comments (Atom)
4 comments:
I have just written for myself a package level logger like so:
package whatever;
import java.util.logging.Logger;
class PackageLogger { // package
private PackageLogger() {
package_name = this.getClass().getPackage().getName();
log = Logger.getLogger( package_name );
}
private final String package_name;
private static final PackageLogger instance = new PackageLogger();
static PackageLogger get_instance() { // package
return instance;
}
private Logger log;
Logger get_logger() { // package
return log;
}
}
Usage is
Logger log = PackageLogger.get_instance().get_logger();
I went with the singleton so I could use this.getClass... but I don't suppose it matters when the class name will always be the same.
P.S. Is there any way to get Blogger to leave your code alone?
P.P.S. Do you prefer working with Eclipse?
Well in static case you can get to the Class reference by using .class e.g.
PackageLogger.class.getPackage().getName();
In any case your approach the logger instance gets created eagerly but has an advantage of being multi-thread safe. I should add synchronization block around the logger instance creation.
It seems you could try using the pre HTML tags around your code to see if that helps.
Yes I prefer working with Eclipse. In fact I love working with Eclipse.
I've tried <pre> and <code>, but neither are allowed.
I'm pleased you have the chance to work with an environment you love.
I have used your rectangular edit tool for some time, and have got into the habit of searching 'sandipchitale' in the (appalling) plugins portal search engine for NetBeans. Have you described anywhere the reasons for your preference?
Is the difference related to the central place of ant in NB, or is there awkwardness of design that is independent of that decision?
You are in the very rare position of having a lot of experience in writing plugins for both NB and Eclipse. I think that many people would be interested in your opinions.
(I started using NB when I started with Java 5, early in its lifetime, and NB was the only free IDE that supported J5. I'm a creature of habit, and old affections die hard, so I would like to see it improve.)
I think that Eclipse simply has always had a comprehensive approach to the IDE. Especially IMHO the support for developing plug-ins is far superior in Eclipse. I attribute this to the schema based extension-points (as opposed to the layer files magic in NetBeans), all the wizards, views, extension points, launchers, builders and on and on... When I was working on NetBeans I said the same thing. That is why I was writing all those modules to make it at par with Eclipse. Having said that I must say that NetBeans has improved a great deal since the NetBeans 4.0 days.
Post a Comment