logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From c..@qos.ch (Ceki Gulcu)
Subject Re: Revised API Proposal
Date Thu, 06 Sep 2001 06:45:43 GMT


As you are probably aware, the recently checked in code follows your
proposal even if hours of previous work had to be thrown out to get

Your scheme is less intuitive then my initial proposal where Category
extends Logger Category. However, it has the distinct advantage of
fully preserving backward compatibility whereas my scheme is broken
beyond hope.

Thank you for your bloody brilliant contribution. Regards, Ceki

> Objective
> ---------
> Gradually remove the Category class in favor of Logger:
> a) starting today, it should be possible to use log4j without ever
> seeing a reference to category (be it the class Category or any method
> or exception containing the word "category").  An added feature would
> be that a new user of log4j doesn't ever see category in the doc
> (javadoc or else).
> b) it should be possible to make code that uses Logger and code that
> uses Category live together to ease migration and also because a
> complex application collaborates with other externally written classes
> (a framework or a library for example), and these would migrate at
> different rates.  
> c) at some point in the future the Category class will disappear 
> replaced by Logger.
> One solution
> ------------
>   Category
>      ^
>      |
>      |
>    Logger
> a) introduce the Logger class as a simple subclass of category (no
> new method nor instance variable, just the same constructors).
> b) deprecate class Category
> c) replace all the Category constructor calls with Logger
> constructor calls.
> d) modify all methods in log4j code:
> 	 Category aMethod(Category aCategoryParameter)
>    - to return Logger objects instead of Category (cannot break
>      existing code that is expecting categories because Logger "is-a"
>      Category)
>    - to keep accepting Category arguments (generosity towards old code)
>   that is:
> 	Logger aMethod(Category aCategoryParameter)
> e) for all methods (static or else) that contain the word "category" in their
>  name create an exact copy of the method with the word "category" replaced
>  by "logger". Deprecate the method containing the word category, of
>  course use the new method in the rest of the code.
>    For example, for the method xxxCategory() create new method
>    xxxLogger() while deprecating xxxCategory().
>    To the best of my knowledge there are no log4j methods names
>    containing the word category.
> f) exceptions: To the best of my knowledge there are no log4j
>    exceptions containing the word category.
> All log4j code should compile without any warnings with the
> -deprecation flag.
> Discussion
> ----------
> a) this solution fills all requirements listed in the objective except that
>  it is unclear from the javadoc that Category should not be used because of
>  the method parameters that are declared with Category.
> b) for public class and instance variables there is no clean way to enforce
>  compatibility other that duplicating variables
> c) adding the Logger type under Category may have some performance
>  impact.
> d) At a later distribution of log4j, simply dropping the Category 
> class by moving all its code to the Logger class should be easy.
> Nicholas Wolff

To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org

View raw message