commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: [Configuration] experimental branch uses java.util.logging?
Date Wed, 03 Jun 2009 00:18:33 GMT

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:
> 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message