commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: [DISCUSS][POOL] Logging options for Pool2
Date Fri, 10 Feb 2012 20:34:03 GMT
The better thing to do would be to point you to http://logback.qos.ch or http://people.apache.org/~rgoers/log4j2/.
 Compare the features in either of those against JUL.

When building a framework you can't look at logging in isolation. Nobody wants to configure
JUL and Logback and Log4j, etc.

Ralph

On Feb 10, 2012, at 12:14 PM, Simone Tripodi wrote:

> Hi Ralph,
> 
> just for a matter of curiosity and filling my lacks of knowledge, can
> you point me please to some doc about the lacks of j.u.l. ?
> 
> Many thanks in advance, all the best!
> -Simo
> 
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
> 
> 
> 
> On Fri, Feb 10, 2012 at 9:07 PM, Ralph Goers <ralph.goers@dslextreme.com> wrote:
>> 
>> 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 well.
>> 
>>> 
>>> 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.
>> 
>> Ralph
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


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