commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: [DISCUSS][POOL] Logging options for Pool2
Date Fri, 10 Feb 2012 21:00:52 GMT
Hi Ralph,

log4j2 looks really promising, I'll join the logging ML.

And nice to see fluido-skin in action :P

-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:34 PM, Ralph Goers <ralph.goers@dslextreme.com> wrote:
> 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
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message