[slf4j-dev] jul-to-slf4j bridge via LogManager, prototype

[Ceki Gülcü]

Hello Max,

Thank you for this contribution. Perhaps a stupid question but what is
the purpose of replacing jul's LogManager and creating a Logger class
extending java.util.logging.Logger? You say that you were unsatisfied
with the existing jul-to-slf4j adapter, how so and how does your
implementation improve things?


On 04/03/2010 6:36 AM, Max Mustermann wrote:
> Hi!
>
> Being unsatisfied with existing jul-to-slf4j adapter I tried to search
> for a better way to bridge jul to slf4j
>
> Attached you find a prototype implementation based on the following
> concepts:
>
> * A jul LogManager extending java.util.logging.LogManager creating newly
> introduced org.slf4j.bridge.Logger subclassed from java.util.logging.Logger
> * setting LogManager via jvm property:
> -Djava.util.logging.manager=org.slf4j.bridge.LogManager
> * adding LogManager / Logger to bootclasspath:
> -Xbootclasspath/a:path/to/jul-to-slf4j.jar
> * LogManager has mapping for jul logging call source Level to target jul
> Level, mapping for target jul Level to slf4j log methods: e.g. source
> Level.FINEST -> target Level.FINE, target Level.FINE -> slf4j trace
> * LogManager mapping hardcoded but possibly configurable by
> adapting/improving readConfiguration() / readConfiguration(InputStream)
> * A org.slf4j.bridge.Logger extending java.util.logging.Logger that has
> a very simple lazy slf4j logger lookup + forwarding of most methods to
> slf4j methods. NEEDS IMPROVEMENT: logrb methods, entering, exiting,
> throwing, etc.
> * As org.slf4j.bridge.Logger is probably instantiated very early in
> system startup (replacing sun internally used Logger instances as well)
> it cannot be assumed that slf4j is already in classpath. So I have done
> a lazy lookup of Slf4j Logger via reflection. If found, it keeps a
> reference (possible memory leak?), if not, it falls back to
> java.util.logging.Logger super calls. The slf4j method invokations are
> therefore via reflection as well. Possible performance improvments by
> caching Method elements, maybe use java.lang.reflect.Proxy, bytecode
> rewriting, ... ?
>
>
> Tried it with jboss-4.2.3.GA and it seemed to work.
>
> greetings, Jürgen
>