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
__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger
http://im.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
