This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Inspired by NbPreferences.forModule(), which returns a Preferences node for the whole module, I propose a method to create per-module java.util.logging.Logger's. This method could be useful in modules which need to log in a few places only and would use Logger.global if that was permitted. It could also help keep the number of loggers down (no logger per class unless really needed) while avoiding forcing users to come up with their own scheme of maintaining a logger per module. It e.g. be used to replace ErrorManager.getDefault().log() calls, where it could be a better choice than Logger.getLogger(Foo.class.getName()).log(). I would like this method to be NbLogger.forModule(), but Yarda preferred Exceptions in order to avoid yet another small class in o.o.util, so it's Exceptions.getLogger(). I will add Javadoc, tests, etc. if the feedback is encouraging.
Created attachment 43529 [details] Proposed change
Very nice, I like this feature, and plan to use it when the need arises. Code looks good.
What's wrong with simply calling Logger.getLogger(clazz.getName())? I don't see the problem with having one logger per class. In fact it seems preferable since you leave open the option of finer-grained control over logging levels.
Nothing is wrong with it, with the exception that it creates unnecessary loggers which live forever. If in a module that doesn't otherwise make use of logging I need to log a warning in three classes, I have just created three loggers, which seems too much for what I need to do. You're right about the fine-grained control, but when you need to do that you have probably already devised a logging scheme, you would need more control over your loggers and wouldn't need Exception.getLogger(), which is intended for the simple cases.
Is there actually any noticeable overhead per logger instance? Have you measured? You don't need any particular "scheme" just to call Logger.getLogger(ThisClass.class.getName()). Seems pretty simple already.
+1 on Jesse's objections. If deemed useful however, I think your original idea of NbLogger.forModule() is easier to find and use than Exceptions.getLogger().
So far I did not see logging code to be a bottleneck for our runtime performance or memory consumption. Logger creating is very fast action and it is lightweight data structure usually held by static field in your class and through hashtable in j.u.l.LogManager. While talking about cost: the proposal brings yet another contract into global lookup to be able to get module base name. If you really want only a few occurrences of logging code why not to use package private Logger (using class or package name).
OK, closing then.