commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Brown <>
Subject Re: [Configuration] experimental branch uses java.util.logging?
Date Fri, 19 Jun 2009 08:01:08 GMT
I'd be happy to be proven wrong, but isn't there one huge disadvantage of
JUL - lack of per-webapp configuration?  How would one webapp decide to
redirect JUL to a file without affecting any other webapp in the same JVM?
If this is indeed the case, JUL is a showstopper for any webapp that can't
assume they are the only webapp in the JVM, which is just about everyone.


On Thu, Jun 18, 2009 at 9:28 PM, Emmanuel Bourg <> wrote:

> Ralph Goers a écrit :
>  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.
> And everything ends in log4j, where redirecting JUL requires just one line
> in your configuration.
> Commons Logging and SLF4J made sense in a pre-Java 1.4 world. Today they
> are just a hindrance inherited from the past.
> Btw I'll happily change my mind if someone demonstrates that the JUL
> bridging isn't viable in production and causes unsolvable memory leaks or
> horrible performances.
> Emmanuel Bourg
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message