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

Reply via email to