Re: Logging change for Avalon Framework

[Berin Loritsch <bl...@apache.org>]

Berin Loritsch wrote:
> 
> > > Please let me know ASAP.  If there are no issues, then I can
> > > get busy preparing a new release of Avalon Framework.  If the impact
> > > is much worse than anticipated I need to know.  That way I can back
> > > out the changes or add a different Loggable equivalent interface
> > > that uses the new Logger interface.
> > >
> > > If all goes well, there should be little to no impact on your
> > > projects.

All did not go well, and the change proved more extensive than I originally
thought.  In order to provide what I originally desired, with the least amount
of impact, I deprecated Loggable.  The new interface of choice is:

interface org.apache.avalon.framework.logger.LogEnabled
{
    void enableLogging( org.apache.avalon.framework.logger.Logger logger );
}

By using the LogEnabled interface, you may use the included adapters for
Log4J, LogKit, or JDK 1.4 logging.

There are some things that I do need to explain regarding the side affects
of using the LogEnabled interface:

1)  The Logger you have is Opaque--it cannot be downcast to the originating
    logger type.  This is a design goal, but if you need to work with Loggable
    components in your system, you must use the Loggable interface yourself.
    Otherwise there is no way to get the org.apache.log.Logger from the one
    supplied to you--nor can you assume that the Logger you have been given
    is a LogKit logger (IOW, you can change logging frameworks without touching
    the rest of your code).

2)  If you are using JDK 1.4 logging, there is no direct mapping between the
    priorities we define and what JDK 1.4 defines.  We wanted to remain as
    consistent as possible, so below is the mapping:

    * debug()      -> FINE
    * info()       -> INFO
    * warn()       -> WARNING
    * error()      -> SEVERE
    * fatalError() -> SEVERE

    While it would have been possible to change error() to WARNING, warn()
    to INFO, and info to CONFIG, that would have been confusing when you look
    at the log files.

3)  ExcaliburComponentManager and the Pool implementations must remain Loggable
    instead of LogEnabled.  It was not possible to upgrade them without breaking
    backwards compatibility.

-- 

"Those who would trade liberty for
 temporary security deserve neither"
                - Benjamin Franklin

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>