Hi,
I'd just like to note that I've found it common for the Log4J Category
to clash with one of my own classes named Category. As you note, the
meaning of Logger is overloaded but I think that Logger is less likely
to clash in a software system than Category. (This problem is of course
easily worked around by the standard practice of prefixing one's class
names with some constant which is necessary in many cases anyway for
lack of a powerful module system in Java.)
More important are semantics. As a programmer I want to send a message
to the logging subsystem. In that respect statements like
Logger.trace(foo) more closely describe my (the programmer's) intention
than Category.trace(foo). Category effectively exposes implementation
details that I would rather like to see abstracted away.
Third, there may or may not be merit in mimicking the Sun API as closely
as possible. From direct experience I know that Sun APIs, as inferior as
the may be, tend to become defacto standards. Making migration and
drop-in replacement easy can be valuable.
In the case of the Cryptix JCE this involved creating a thin Java 2
compatibility shim so that a single Cryptix JCE binary could support
Sun's API on JDK 1.1.x and Java 2 platforms. In that particular case the
extra work was well worth it. On the other hand, Sun's logging API is
much worse than their Java Cryptography Extensions API (hard to
believe!). It is purposely put in a namespace that cannot be backward
compatible with JDK 1.2/1.3, screwing over any developer that cares
about backward compatibility. <sigh>
Whatever comes of it, I'd just like to state that Log4J is one of the
most pleasant packages to work with. I do not have any problem accepting
the above-mentioned limitations if Log4J remains the best solution to my
logging requirements.
Cheers,
Jeroen
--
Jeroen C. van Gelderen -- [EMAIL PROTECTED]
-----Original Message-----
From: Christopher Taylor [mailto:[EMAIL PROTECTED]]
Sent: Saturday, September 01, 2001 22:20
To: LOG4J Developers Mailing List
Subject: Re: Revised API Proposal
Speaking of documentation, that brings up a good point:
- If we change the class to "Logger", the docs need to be changed
- What about the configuration file structure? Do we leave them as
"categories", or rename them "loggers"? If we change it over to
loggers, it
doesn't make sense: "com.java_internals.servlet" is a category, but a
logger?
I really don't see the benefit of a name change, but I'm only one
person.
-Chris
P.S. Logger could also be someone who harvests trees. It all depends on
context (when I read the overview docs for Log4J, I understood
immediately
the Category, Appender, and Layout concepts).
----- Original Message -----
From: "Jason Dillon" <[EMAIL PROTECTED]>
To: "LOG4J Developers Mailing List" <[EMAIL PROTECTED]>
Sent: Sunday, September 02, 2001 10:37 AM
Subject: Re: Revised API Proposal
> > The problem I have with calling it a Logger is that it hides the
concept
of
> > Categories from the developer.
>
> Isn't that what documentation is for?
>
> I personally think that Logger is better than Category. Logger shows
that
> the object is used for logging messages, where Category could be an
object
> for a game show application, something to used classify animals or
part of
a
> generalized catalog application.
>
> Most developers I work with don't really care too much about the
internals,
> they simply need an API to inject log messages, though those folks
probably
> don't care too much if you called it Hamburger I would bet.
>
> my $0.02, go with Logger, create deprecated sub-classes called
Category
for
> backwards compatibility. If Logger turned into an interface then a
dynamic
> proxy could be used to make this compatiblity translation, but that is
a
> different matter all together.
>
> --jason
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
