[logback-dev] Better introspection into logging setup

[Ceki Gülcü]

I suggest that you file a jira issue against logback-classic so that whenever 
the level of a logback-classic logger changes this is mirrored in jul. Packaging 
such functionality into SLF4J would be out of scope.

On 02/03/2010 2:00 PM, Durchholz, Joachim wrote:
>> Having this API as part of SLF4J would allow to have a JUL
>> bridge which is agnostic of the actual logging backing. But a
>> valid questions remains, if such API should be added to SLF4J
>> just because of the JUL bridge.
>
> *Something* should be done considering that JUL is going to be around
> for at least another decade, and that JUL kills performance if it's
> configured with the root logger at Level.ALL.
>
> I see two approaches:
> 1) Improve the JUL bridge so that it installs only loggers where the
> SLF4J configuration wants one. This requires minimal access to the
> backend's configuration.
>
> The question is what to do.
> Currently, I see two variants:
> 1) Improve the JUL bridge.
> 2) Improve the JUL bridge docs and tell people how to configure JUL so
> that the JUL bridge performs well.
>
> (Variant 2 seems doable to me. I think JUL bridge performance can be
> returned to acceptable levels by
> - configuring those third-party libs that use JUL via the JUL facilities
> and
> - configuring the SLF4J backend at Level.ALL for the logger namespace(s)
> of said libs.
> I wouldn't like to keep logging configuration in two separate files, and
> I haven't tried it yet, but it could be done... the question is: what
> approach would fit better with SLF4J? I can't answer that last
> question.)