I agree with what Jim said about "Logger" being far more intuitive than
"Category". But ... I do have a soft spot for the term for the following
reason. When I first took a look at log4j, I looked in the package for a
class called "Logger" and, of course, didn't find one. When I found out
the "Category" class did the logging, I was hell-bent on understanding why
it was called a Category. It wasn't until I understood category
relationships that I began to see the power the idea had. If it had been
called Logger, I never would have bothered with studying it closely.
It's a Category and it's a Logger. But the Category aspect is more subtle.
Calling it a Logger would be far more intuitive, but further obscure the
Category benefits. I like Jim's analogy with X Servers: you always have to
explain why the client/server relationship seems backwards. The question
becomes whether to pacify the ignorant (not stupid !!) by lowering the
entrance barrier at the cost of the change.
If the decision is made to change, we might want to bump up the release
digit in source control (Log4j 2.0), jetison backwards compatibility with
both Log4j 1.x and JDK 1.1.x and preserve Log4j 1.x in maintenance mode
only (no new features, just bug fixes for a while). This would imply a
branch in our CVS tree, something that is probably not too popular;
maintaining separate older versions never is.
- Paul
Paul Glezen
IT Specialist
Software Services for WebSphere
818 539 3321
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
