commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <>
Subject Re: [jcs] logging
Date Tue, 03 Jun 2014 15:44:45 GMT

Send from my mobile device

> Am 02.06.2014 um 21:51 schrieb Romain Manni-Bucau <>:
> @Thomas: never said [logging] is bad and JUL is better. Sorry if I was not
> clear. All logging facades don't handle very well EE case for several good
> or bad reasons. [logging] is as good as slf4j for it (even better out of
> the box IIRC). JUL is far to be perfect but is in the JVM (so no
> dependency). The second point was just an open one. We'll want to get
> JCS/JCache in TomEE in few months and logging is not the best solution we
> have ATM. A little facade/factory would be great but once again this is not
> a blocker now. Mentionned it to let you have it in mind when it will come
> back.
> About 1 you are right and wrong. Right that I keep in mind in memory case
> (concurrenthashmap to caricature it a bit) because it is a very common
> case. Right that JCS is not only it and its biggest value is not here.
> However I can't agree when you say you don't care about this case. JCS is a
> cache and if caching is as slow as the cached computation then it is not as
> useful as it could be. Back to the logging I benched it months ago for
> OpenEJB and it really depends the configuration of the logger and the impl.
> Most of the time it is fine but if you want business debug logs only and
> you have several appenders by logger then you get an noticeable overhead
> (it was shouting in Tomcat classloader which is called very often at boot
> and had a lot of isLogEnabled(FINE) some month ago).
> That said I don't want to fight too long on it so if you really think it is
> wrong you can revert this part and I'll come back with a sample when I'll
> find time to work with it on a real project (until now I only used
> test/sample projects).

I trust Romains assement of this topic.


> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog:
> LinkedIn:
> Github:
> 2014-06-02 20:51 GMT+02:00 Thomas Vandahl <>:
>>> On 01.06.14 21:26, Romain Manni-Bucau wrote:
>>> Hi
>>> I have two main point to discuss regarding the logging:
>>> 1) LogHelper stuffI committed. Idea was to cache isDebugEnabled to get a
>> if
>>> (boolean) complexity and not go through the logging framework which can
>>> imply several layers (filter, appender, handler, logger...) for nothing
>> and
>>> slow down caching (which has more perf constraints than other backends.
>>> This really depends on the logger you use but we can't suppose it is the
>>> one we benched against. Solutions I see: a) keep LogHelper, b) remove
>> logs
>>> (some are useless I think), 3) other?
>> Remember what I said about use cases. You have your one-and-only use
>> case in your mind. Others may have other use cases, accept dependencies,
>> need debugging. A quick scan of the net shows several places where the
>> performance issue has been discussed. Examples:
>> or
>> Both suggest that the isDebugEnabled() call can be neglected for most of
>> the cases. It is not ConcurrentHashMap you are competing with.
>> Create a benchmark, run it and see for yourself. Logging is the least of
>> our performance issues, I promise.
>>> 2) logger api used. ATM we use [logging] but it will surely be an issue
>> for
>>> TomEE when integrated ([logging] is the less integrated framework -
>>> compared to JUL or SLF4J where we don't have the choice at all) and I
>> think
>>> we'd be happy to remove it from the container to let it be application
>>> oriented if we can. Any idea to make it hurtless? This doesn't urge and
>>> doesn't block anything but if someone has an awesome idea it would be
>>> welcomed ;)
>> I'm not sure I understand what you want to tell me. Do you consider it
>> good manners to jump into a community and tell them right away how
>> shitty their logging framework is? My experiences with JUL are no better
>> by the way.
>> That said, I don't really care about the logging framework. Move to JUL
>> if you believe it's faster. But please avoid shooting yourself in the
>> foot by prematurely optimizing things and removing important features.
>> Bye, Thomas.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

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

View raw message