Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ant-dev@jakarta.apache.org
Message-Id: <3.0.6.32.20010510124054.00af7100@mail.alphalink.com.au>
Date: Thu, 10 May 2001 12:40:54 +1000
To: ant-dev@jakarta.apache.org
From: Peter Donald <donaldp@apache.org>
Subject: Re: [Vote] Logging 
In-Reply-To: <20010510012652.24135.qmail@mailweb30.rediffmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 01:26  10/5/01 -0000, Magesh Umasankar wrote:
>To perform a simple log operation in Log4J:
>
>   Category  cat = Category.getInstance("com.foo");
>   cat.setPriority(Priority.DEBUG);
>   cat.debug("Debug Message"); 
>
>To perform a simple log operation in LogKit:
>   Category cat = new Category("com.foo");
>   cat.setPriority(Priority.DEBUG);
>   Logger logger = new Logger(cat);
>   logger.debug("Debug Message");

Actually if you were to use that model they would be exactly the same ;)
ie.
    Logger logger = LogKit.getLoggerFor("com.foo");
    logger.setPriority(Priority.DEBUG);
    logger.debug("Debug Message");

>Doesn't seem a lot different at least in the simplest of cases.  

True but if you looked at a simple one target "echo" buildfile between ant
and make ... make would look far simpler ;)

>Please explain (probably more complex scenarios) where the simplicity of
LogKit wins over Log4J.

Essentially UI of Logger and use cases designed for. 

UI - Logger interface is less complex - it doesn't try to do
internationalisation. object rendering/logging, or unsafe things like
giving access to hierarchy *shudder*.

LogKit was designed for use in an IOC environment - ie if you have access
to logger about "com.biz" you cannot access "com" in any manner - however
you can get access to further sub-categories. ie Logger sub =
logger.getChildLogger( "foo" ); would get "com.biz.foo" This means you can
never break out of your shell so to speak.

Also most classes who use logger get it provided by their container via
Avalons Loggable interface. Most of these classes extend AbstractLoggable
as a convenience use. Thus a common use case would look like

MyClass extends AbstractLoggable 
{
  void method1()
  {
    getLogger().debug( "MyMessage" );
    MySubComponent msc = new MySubComponent();
    setupLogger( msc, "msc" );
    msc.doWork();
  }
}

In this case it is the container of MyClass that decides the logger
category to provide the object lets say for example it is "foo.bar";
However myclass can also provide loggers to sub components and does so in
this case creating "foo.bar.msc".

Thus to do logging in any of these components it is as simple as 

getLogger().debug( "MyMessage" );

and it will route to correct category. There is also no problem in passing
around loggers as they are all "safely" locked away and you can't reverse
traverse back up. This becomes especially important when we start dealing
wit cases of container tasks (not important for hierarchial builds though -
more on this later).

LogKit is slightly easier to setup but this is irrelevent with respect to
Ant because we will do it once.

Theres a few other nits but the above is the basics.


Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*