Es begab sich aber da Christiaan Fluit zur rechten Zeit 19.02.2007 18:33 folgendes schrieb:
Leo Sauermann wrote:
I would strongly object using any more complicated logger frameworks. 
For a crawling framework like aperture, java.util.Logging is fair enough.

I guess I saw this one coming ;)
yes, that was to be expected :-)
To be totally honest, I don't have a strong preference for either one. 
My only priority is to get things working correctly (hence the change to 
instance loggers), and while I'm at it I could easily make any other 
changes to logging that we might wish for.

As said in other mails to the sesame2 mailinglist, all logging 
frameworks have a limited life span,
given the fact that SUN has now standardized logging.

This is where my lack of knowledge is showing. I have never used 
anything else but java.util.logging. I have no idea whether the other 
frameworks still have any raison d'être other than "for historic reasons".
Me neither, but I know that Java logging did not exist before java 1.4 and that the logging frameworks were started before this.

so an abstraction framework abstracting away different logging 
frameworks will not be needed in a few years.
I see no reason for using SLF4J. IF you are dependent on some older 
logging, just do this:

You can forward logging from java.util.Logging to any other framework, 
if you want. Its something like
// remove java loggers from aperture
Logger.getLogger(org.semanticdesktop.aperture).removeAllHandlers() // 
this method may not exist, but its possible to code in two lines
// forward the java log messages to another framework

About static/instance logging, if this is needed, just use this code,
I had some classes (which have subclasses) where this helped:

  protected Logger log = Logger.getLogger(this.getClass().getName);

Yeah, that's what I also had in mind, expect for that I would keep the 
instance private: subclasses should create their own logger, so that you 
can see which *class* is doing the logging. Else subclasses that 
override methods and use the logger of the overridden class get very 
curious log messages. Only in very specific cases, where a lot of 
loggers are generated and the cost becomes non-negligible (never seen 
yet), could we look at such approaches.
On the other hand, using private loggers may have the effect that you don't get the real classname doing the logging - this is also bad when having generic superclasses that do important things.
Lets assume something like

  private Logger log ...
 startCrawling() {
  log.fine("I start crawling now");
FileCrawler extends AbstractCrawler{
   private Logger log ...
  doThings() {
   log.fine("I am doing things");

This will result in messages like this (version A):
[AbstractCrawler] I start crawling now
[FileCrawler] I am doing things

When really what you would need is (version B)
[FileCrawler] I start crawling now
[FileCrawler] I am doing things

its easiser to debug (and thats what log messages are for, or?) if you can see all the messages that belong together in one logger. For example, we have a window that shows log messages, sorted by logger. If you use such a display, version A will cause troubles because you don't see the start-message and think: why is the crawler doing things before he even started? In version B, its better.

The BEST way to do it, in my opinion is,
  protected Logger log = Logger.getLogger(this.getClass().getName);
Subclasses can then access the logger, and all is fine. Messages generated in the superclass use the correct class of the instance. Think of abstract classes, their loggers are pretty useless if you don't know the real instantiated class.

Do you know cases where this is not intended and the loggers need to be private?

Note, that also creating a logger for each instance creates a LOT of unneeded instances, fills memory and wastes resources, so I would really not do it. Logging is for debugging, and using instance loggers just doesn't pay off for debugging, given the cost we pay during runtime. or? Although i didn't think about it that much....


I will at least make the switch to instance loggers then.


Take Surveys. Earn Cash. Influence the Future of IT
Join's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
Aperture-devel mailing list


DI Leo Sauermann 

Deutsches Forschungszentrum fuer 
Kuenstliche Intelligenz DFKI GmbH
Trippstadter Strasse 122
P.O. Box 2080           Fon:   +49 631 20575-116
D-67663 Kaiserslautern  Fax:   +49 631 20575-102
Germany                 Mail:

Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313