commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: [DISCUSS][POOL] Logging options for Pool2
Date Fri, 10 Feb 2012 20:07:02 GMT

On Feb 10, 2012, at 7:02 AM, Mark Thomas wrote:

> Yeah, that isn't going to work. I really do wish java.util.logging had
> been designed with JavaEE in mind. Clearly it wasn't. We tried fixing
> this in Tomcat but even with JULI the APIs just aren't available to do
> this. You could do JVM specific hacks but they will break just as soon
> as the JVM vendor changes their internal API (as they are perfectly
> entitled to do). In the end, Tomcat categorized this problem as WONTFIX.

Sorry, JUL wasn't designed with anything in mind as far as I can tell.  It sucks as a facade
and the implementation is barely adequate.  I've delayed creating the bridge from JUL to Log4j
2 primarily because all the ways to do it are bad.

> With this in mind, commons-logging is a better choice as it should be
> possible to have an entirely contained logging setup within the
> application and a properly written container shouldn't interfere with
> this. Commons-logging is also relatively simple to redirect to something
> else.

That is the primary reason to use Commons Logging, IMO. Unfortunately, the API is pretty minimal.
> Given the discussion so far has been around commons-logging or
> java.util.logging, I think these two are the front runners. I can live
> with either but I have a very narrow focus - i.e. what can i get working
> easily with Tomcat's packaged renamed version of pool2.

I'm not sure why you'd rule out SLF4J. Although it isn't perfect, as a facade it works pretty

> Taking a wider view, commons-logging is probably the better choice as
> although it adds a dependency, it is easier for folks to integrate with
> their logging framework of choice.

Yes, it is a much better choice than JUL just because of that.


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

View raw message