Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail
From: markspace <-@.>
Newsgroups: comp.lang.java.programmer
Subject: Re: Aspect questions?
Date: Sat, 25 Feb 2012 20:22:01 -0800
Organization: A noiseless patient Spider
Lines: 69
Message-ID: <jicc1d$er6$1@dont-email.me>
References: <XnsA0039B9FFFA32jpnasty@94.75.214.39> <ji8u23$f6m$1@news.albasani.net> <XnsA00493ECED98jpnasty@94.75.214.39> <jia398$bho$1@news.albasani.net> <XnsA0047B96E59BFjpnasty@94.75.214.39> <jibf3u$ee9$1@news.albasani.net> <XnsA004B034AE631jpnasty@94.75.214.39> <4f496d47$0$289$14726298@news.sunsite.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 26 Feb 2012 04:22:06 +0000 (UTC)
Injection-Info: mx04.eternal-september.org; posting-host="XjIWM99mD7Ijfdu600oVPA"; logging-data="15206"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18LEujDOhiTpvHNQOlLJSx4xwQqDeabW9w="
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
In-Reply-To: <4f496d47$0$289$14726298@news.sunsite.dk>
Cancel-Lock: sha1:XXjoWoAhAT1PJ+h7AynQC97lwmE=
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:12351

On 2/25/2012 3:22 PM, Arne Vajhøj wrote:

> That looks as if you are almost building your own logging framework
> on top of a logging framework.
>
> That does not make much sense to me.


I can think of a use case for it though.  Let's say you haven't decided 
which logging framework to use, or you want to be flexible as to which 
one to use.  (Different customers of yours prefer different loggers.)

(Not syntax checked or tested.)

abstract class MyLogger {

   public static MyLogger getLogger( String name ) {
      MyLogger logger =  Class.forName(
               System.getProperty("me.mystuff.MyLogger.logImpl",
                       "me.mystuff.MyDefaultLogger" ).newInstance());
      return logger;
   }

   public abstract void logStuff(Object...);
}


So the idea is that you wrap the logging framework in your own, and then 
you're free to provide an implementation that matches whatever logging 
framework you choose to use in the future.  Maybe this is not for 
everyone, but I could see its advantages.  Some folks might like 
java.util.Logger, some folks like log4j.  And some might like things 
that I don't know about yet.

A couple of other things.

Lew wrote:

  public class Foo
  {
    final Logger logger = getLogger(getClass());
[...]
   }

This requires that a logger is instantiated for each object as it is 
created.  Potentially this is a lot of work, and each logger may not be 
used.  (Even declaring the logger to be static still requires a logger 
per class loaded.)

Whereas this:

   ...
   try {
     ... some stuff...
   }  catch (Exception ex) {
     getLogger(getClass()).log( ... );
   }

creates the logger lazily and therefore doesn't spend any resources if 
logging happens to be never required.

Lastly, I don't know about log4j, but I don't think the 
java.util.logging package uses threads when logging.  Any IO operations 
the logger makes will block the calling thread.  I've heard this is 
undesirable in most cases.  So rolling your own framework also gives you 
control over threading issues too, which again might be important for 
some customers.