> If we were to go down the route of having a small
> & simple loggging abstraction in commons then why
> don't we take the most common subset of log4j that
> most people use (i.e the Category class) and provide
> a default implementation that just logs to System.out.
> This is pretty much what has done already -
> apart from I'm suggesting we use the
> org.apache.log4j.Category class name for this and
> ensure that the class is API compatible
> (providing a direct subset).
We had considered that, but it seems a bit of a slippery slope. You may want to log to standard out, but Remy (for example) may argue that we doesn't want any logging at all. So we'll need to create yet another version of log4j.Category that turns that limited subset into no-ops. Suddenly there are a bunch of little JARs floating around with log4j.Category in them.
And then there is the issue that the class is indistinguishable from log4j.Category at runtime. Assuming there are differences in the API, how am I to know when I'm running with "the fully monty" versus when I just have the subset?
Similiarly, it seems likely that those of us who like to use log4j will do all of their development with the "the fully monty" already--likely leading us to use features not contained in the tiny subset version.
Also, what if I want/need to have both log4j.jar and tinyVersionOfCategory.jar in my classpath at the same time?
Besides, isn't this something we would need to sell to the log4j folks?
We did hash this out a bit in previous threads ([httpclient] log4j redux, [httpclient] logging again, [httpclient] logging and testing changes etc.), if you'd like to go back and take a look. In fact, I purposed essentially the same thing you are purposing here: http://www.mail-archive.com/jakarta-commons@jakarta.apache.org/msg02760.html.
My point is, the Java language has mechanisms for these features--having classes with the same interface but different implementations, distinguishing between those implementations, only exposing certain methods, etc. Why not use them directly? The additional code is rather small, and feels significnatly less like a clever hack.
If log4j (or anything else for that matter) can be rejarred/refactored/whatever to create a tiny, implementation agnositic logging API, then we should use that. The commons proposal doesn't preclude that. Currently the commons proposal seems to the only thing that actually *does* that though, which is why it earned my +1.
If something better comes along, we should use it. But in the meantime...
