Endre, Jim, Chris, Paul and others,
Logger is becoming a more widely recognized label. It is also probably
more intuitive. I won't argue about that.
If it were possible/easy to keep backward compatibility with existing
log4j client code and at the same time rename Category to Logger I
would to be in favor of the change as it is much easier to sail with
the wind than against the wind.
The Category class was named the way it was in order to promote the
concept of hierarchical categories. With hindsight, it would have been
wiser to name it Logger because we would not have had the migration
problem we are facing today.
I actually tried to go for the change but had to abort when I realized that
things were getting out of control. It turns out to be quite a massive change
actually.
Let me give you a flavor of the problem:
Here is a very simplified version of the current Category class:
public class Category {
public
static
Category getInstance(String name) {
...
}
public
void debug(Object o) {
...
}
}
Client code looks like:
Category x = Category.getInstance("foobar");
x.debug("hello world.");
Below are a few attempts at Category to Logger renaming:
Attempt I -------------------------------------------------------------
One approach for replacing Category by Logger is the following:
public class Logger {
public
static
Logger getInstance(String name) {
...
}
public
void debug(Object o) {
...
}
}
public Category extends Logger {
// empty class
}
The problem with this approach is that existing client code:
Category x = Category.getInstance("foo.bar");
would not compile because Category getInstance now returns a Logger
and not a Category.
Attempt II: ---------------------------------------------------
public class Logger {
public
static
Logger getInstance(String name) {
...
}
public
void debug(Object o) {
...
}
}
public Category extends Logger {
public
static
Category getInstance(String name) {
...
}
}
The above does not compile. To convince yourself try compiling:
public class X {
int x = 10;
X(int i) { this.x = i; }
public static X moo(int i) { return new X(i); }
}
public class Y extends X {
Y(int i) { super(i); }
public static Y moo(int i) { return new Y(i); }
}
Compiling gives:
> jikes X.java Y.java
Found 1 semantic error compiling "c:/home/cgu/Y.java":
10. Y doo(int i) {
<-------->
*** Error: The return type of method "Y moo(int i);" does not match
the return type of method "X moo(int i);" inherited from type "X".
Attempt III ----------------------------------------------------------
public class Logger {
/**
@deprecated Category class is deprecated.
Please use the {link #getLogger} instead
*/
public
static
Category getInstance(String name) {
// returns a Category object
}
public
static
Logger getLogger(String name) {
// do we return a Category object or a Logger object?
}
public
void debug(Object o) {
...
}
}
public Category extends Logger {
// empty class
}
The getLogger method offers a migration path from Category to Logger.
However, should it return a Category object or a Logger object? If it
returns a Category object, then the user would be able to write
Category x = (Category) Logger.getLogger("foo.bar");
If the getLogger method returned a Logger object, then
Category x = (Category) Logger.getLogger("foo.bar");
would throw a ClassCastException at runtime. In other words, the user
would be more aggressively pushed to migrate. (I favor this later
alternative.)
There are many remaining problems:
Runtime inconsistencies
=======================
If the client mixes Logger.getLogger and CategorygetInstance method we
might get into hairy situations. Example:
Logger logger = Logger.getLogger("foo.bar");
at a later time
Category cat = Category.getInstance("foo.bar");
The second line would throw a ClassCastException at runtime.
Documentation inconsistencies
=============================
Documentation would need to be updated.
Configuration language
======================
The configuration language would need to be changed while keeping backward
compatibility.
CVS inconsistencies
===================
If we check in a intermediary version of the code that does not
compile or that breaks backward incompatibility, then jakarta-GUMP
would detect this and jakarta-projects relying on log4j would not
build under GUMP. This situation could become intolerable if log4j
could not be fixed within a few days and I am not entirely sure we
could guarantee a quick fix.
My message is that renaming Category to Logger is a lot more
complicated than what one would think at first. I am not saying that
we should not do it, I am just saying that the change has to be
planned with care.
I welcome your comments and suggestions. Offers for help are also very
much appreciated, hint, hint. :-)
Cheers, Ceki
ps: My attempt at conversion failed because I attacked the problem at
two fronts simultaneously. I tried to enrich the way hierarchies were
chosen depending on context and at the same renaming Category to
Logger. It was just too much to do in one go.
At 13:53 01.09.2001 +0200, Endre Stĝlsvik wrote:
>On Fri, 31 Aug 2001, Ceki Gülcü wrote:
>
>| >*You* changed the whole package name from org.log4j to org.apahce.log4j
>| >without lifting a eyebrow. But doing this Category->Logger move which is
>| >such a much more intuitive change you wont do.. Hmm..
>|
>| Is this a provocation? Wishing you a good weekend, Ceki
>
>No, not really. I just find the name Category not very intuitive. And
>doing the org.log4j - org.apache.log4j move was no big hassle,
>apparently, while aligning towards the java.logging API apparently is
>very difficult.
>
>You are definately doing one really good job with this logging pacakge,
>Ceki, but I just got a bit weirded out by your "It stays this way, and
>that's it" message. Not very open, was it?
>
>Have a real good rest of the weekend you too,
>Endre
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
--
Ceki Gülcü - http://qos.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
