On Jun 2, 2009, at 1:48 PM, Emmanuel Bourg wrote:
Ralph Goers a écrit :
From what I can gather from this conversation:
a) This is important to only a small group of us.
b) No one is against having CC switch back to Commons Logging.
c) Some are very much against using a facade other than Commons
Logging, for whatever reason.
I did the change to java.util.logging to reduce the dependencies,
and because JUL can also be used as a facade as demonstrated by Paul
Smith with the log4j bridge:
http://people.apache.org/~psmith/logging.apache.org/sandbox/jul-log4j-bridge/examples.html
Logging is not critical to Commons Configuration (unlike an
application server for example), there is no need for a
sophisticated framework. As a library it shouldn't impose a
dependency if it can be avoided.
I disagree on both counts. Logging is critical to everything.
Debugging problems can be quite difficult if logging isn't done well.
Commons Logging isn't all that sophisticated IMO and using JUL as a
facade isn't all that practical and just because it can be done
doesn't mean it should be. The problem here is that JUL isn't really
meant to be a facade and users picking up Commons Configuration would
like Commons Configuration's logging to be integrated with their own.
So having a "real" facade is of great benefit as the user will just
configure their system for Commons Logging and be done with it. I do
this with my applications and haven't yet had to configure a facade
for Commons Logging as virtually nothing I am using in my environment
uses it. Virtually everything I am picking up uses Commons Logging or
SLF4J these days.
I just have to rant a little bit more. I'm really trying hard to
understand why you would think logging in an application server is
more important than logging in the applications running in the
application server. If anything, it is the other way around.
Typically, problems in production are not in the app server but in the
application. Furthermore, incorrect configuration information to an
application - especially in a situation like mine where a single
application is running with more than 1800 possible configurations -
can often be the root cause of many application errors.
As for dependencies, removing them for the sake of removing them isn't
necessarily the right thing to do. For example, I noticed attempts to
move away from Commons BeanUtils. For the life of me I can't
understand why anyone would want to do that, especially when the code
that replaced it was less functional.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
