Hi Ben,
yes, you understood it correctly.
The main problem is that you have to decide about the lowest level
that you'll ever receive from the BridgeHandler.
Everything above that level will generate a logging event in
j.u.logging. Only after that event has been generated (including fully
generating its message), the actually used SLF4J implementation will
have a chance to drop it.
This is very unfortunate and is the main reason why I consider
j.u.logging the worst logging API out there.
Regards,
Joern.
On 12.04.2010, at 17:10, Ben Pickering wrote:
Hi
In our application we use several libraries that log using
j.u.logging, and we want to send them to the slf4j-wrapped logback
setup we use everywhere else. For this we're using the
SLF4JBridgeHandler class.
On the Javadoc page for SLF4JBridgeHandler http://www.slf4j.org/api/org/slf4j/bridge/SLF4JBridgeHandler.html
there's a warning that the class comes with a performance cost, and
I'm keen to understand the nature of this.
My assumption is that the issue relates to the case where the
j.u.logging level is finer than the logback level. Processing done
by j.u.logging is wasted because a logging call never results in a
message being written; it never 'makes it through' logback because
of its higher level. If the library is generating lots of FINEST
calls, this could be a hit.
However, if the j.u.logging level is set high, e.g. to INFO, then
j.u.logging itself never makes the effort, and so there'll be no
additional performance impact.
Is this a correct assessment? Or is there more that I should be
aware of?
_______________________________________________
slf4j-user mailing list
[email protected]
http://qos.ch/mailman/listinfo/slf4j-user
_______________________________________________
slf4j-user mailing list
[email protected]
http://qos.ch/mailman/listinfo/slf4j-user
