Ceki> Category class being a class and not an interface
Ceki> has some disadvantages. At the time, it was a
Ceki> deliberate decision in favor of performance. If I
Ceki> had to do it again, I'd probably do it differently.
Ceki>
Ceki> As I said, I am all in favor of refactoring the
Ceki> log4j API but only if we can ensure a smooth
Ceki> transition path. Regards, Ceki
Costin> Actually, I totally agree with this, changing Category
Costin> is a bad idea.
Costin>
Costin> What I had in mind is getting some of the ideas
Costin> from Logger, and create a _new_ abstract class
Costin> that contains the user part of Category. Then
Costin> Category can extend that class.
Costin>
Costin> You can also create another (optional)
Costin> LogConfiguration or LogManager abstract class,
Costin> with the methods the user can safely call, and
Costin> have Hierarchy extend this class.
Costin> [...]
Costin> ( and in future we'll use Log instead of
Costin> Category and LogManager instead of Hierarchy :-)
Costin>
Costin> Of course, this is just one choice. There are
Costin> many other ways we could get log4j to satisfy some
Costin> (justified) requirements, while keeping backward
Costin> compatibility.
As I've mentioned several times, I fully agree with this general approach.
The trouble is, it will take a fair amount of time to work though this. In
the meantime, I need logging. I need 1.0 releases of commons components.
Hence the logging proposal.
That doesn't mean we shouldn't pursue a solution like the above (in fact, I
think we should pursue a solution like the above) but in the interim the
logging abstraction seems harmless enough. When something better comes
along, let's move to that, but some progress is better than no progress, and
no progress is what we get when half the team is saying "if it's logging,
it's log4j" and the other half is saying "log4j dependencies are
unacceptable".
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
