Hi Sam,
Logger is not speculative. Logger *is* Category. Here is the
actual (real) code of Logger:
package org.apache.log4j;
public class Logger extends Category {
protected
Logger(String name) {
super(name);
}
static
public
Logger getLogger(String name) {
return LogManager.getLogger(name);
}
static
public
Logger getLogger(Class clazz) {
return LogManager.getLogger(clazz.getName());
}
public
static
Logger getRootLogger() {
return LogManager.getRootLogger();
}
}
Let me emphasize that the goal in the change is not to
replicate the JSR47 API but to adopt a more widely accepted name
(Logger instead of Category). I don't expect any changes in Logger
even if JSR47 changes -- famous last words!
This is from Category.java:
This class has been deprecated and replaced by the {@link Logger}
<em>subclass</em>.</b> It will be kept around to preserve backward
compatibility until early 2003.
<p><code>Logger</code> is a subclass of Category, i.e. it extends
Category. In other words, a logger <em>is</em> a category. Thus,
all operations that can be performed on a category can be performed
on a logger. Whenever log4j is asked to produce a Category object,
it will instead produce a Logger object. However, methods that
previously accepted category objects still continue to accept
category objects.
<p>For example, the following are all legal and will work as expected.
<pre>
// Deprecated forms:
Category cat = Category.getInstance("foo.bar")
Logger logger = Logger.getInstance("foo.bar")
Category cat = Logger.getLogger("foo.bar")
// Preferred form for retrieving loggers:
Logger logger = Logger.getLogger("foo.bar")
</pre>
<p>The first tree forms are deprecated and should be avoided.
<p><b>There is absolutely no need for new client code to use or
refer to the <code>Category</code> class.</b> Please avoid
referring to it or using it.
After log4j 1.2 comes out users should not use the Category class at all.
The deprecation of Category.getInstance and Category.getRoot helps to push
that point across.
All the new code that I write (outside log4j) uses Logger and a pre-alpha
version of log4j. It all works just fine because Logger is Category.
Does this make more sense? Cheers, Ceki
ps: I just committed the un-deprecation change you requested.
At 13:42 10.09.2001 -0400, Sam Ruby wrote:
>Ceki G�lc� wrote:
>>
>>>What is the target date for removal of these methods?
>>
>> Err, 1Q 2003 (no joke).
>>
>> [snip]
>>
>> I think that
>> the @deprecation flags should be reintroduced before log4j 1.2
>> alpha/beta/whatever is released.
>
>I guess my question is, given the target date, what's the rush?
>
>> Gump is tremendously useful. However, there was no intention to get
>> the "word" out through Gump. See below.
>
>What message do you *WANT* to get out?
>
>In other projects, I have built two branches - one stable, and one
>speculative. Should I consider doing something similar here? Given what
>you have said so far (particularly, given the rather distant target), what
>I would recommend is a release or two where both API's are equally
>supported, followed by a period of deprecation, followed by the removal of
>one vs. the other.
>
>I guess what I am saying is that from my point of view, for the moment,
>Category is stable and dependanble. Logger is speculative and may see
>minor changes over the next log4j release or so (particularly if JSR 47
>changes). Depending on their needs, 1.2 users may want to prefer one over
>the other. Eventually, however Category will be deprecated and ultimately
>removed. Is this a fair assessment of the current situation?
>
>- Sam Ruby
>
>
>---------------------------------------------------------------------
>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]
