<body bgcolor="#ffffff" background="https://img.web.de/v/p.gif" class="bgRepeatYes" style="background-repeat: repeat; ; background-color: rgb(255, 255, 255); color: rgb(0, 0, 0); font-family: verdana,geneva; font-size: 9pt; padding-left: 0px;" ><div style="min-height: 200px; background-image: url(https://img.web.de/v/p.gif); background-repeat: repeat; background-color: #ffffff; font-family: verdana,geneva; font-size: 9pt; padding-left: 0px;">
<p><span style="font-size: 9pt;"><span style="font-family: verdana,geneva;"><span style="background-color: transparent;"><span style="color: #000000;"><span style="color: #000000;">Hi!<br /><br />Being unsatisfied with existing jul-to-slf4j adapter I tried to search for a better way to bridge jul to slf4j<br /><br />Attached you find a prototype implementation based on the following concepts:<br /><br /> * A jul LogManager extending java.util.logging.LogManager creating newly introduced org.slf4j.bridge.Logger subclassed from java.util.logging.Logger<br /> * setting LogManager via jvm property: -Djava.util.logging.manager=org.slf4j.bridge.LogManager<br /> * adding LogManager / Logger to bootclasspath: -Xbootclasspath/a:path/to/jul-to-slf4j.jar<br /> * 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<br /> * LogManager mapping hardcoded but possibly configurable by adapting/improving readConfiguration() / readConfiguration(InputStream)<br /> * 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.<br /> * 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, ... ?</span></span></span></span></span></p>
<p><br />Tried it with jboss-4.2.3.GA and it seemed to work.</p>
<p>greetings, Jürgen</p>
</div> <br><br><table cellpadding="0" cellspacing="0" border="0"><tr><td bgcolor="#000000"><img src="https://img.web.de/p.gif" width="1" height="1" border="0" alt="" /></td></tr><tr><td style="font-family:verdana; font-size:12px; line-height:17px;">WEB.DE DSL: Internet, Telefon und Entertainment für nur 19,99 EUR/mtl.! <br>http://produkte.web.de/go/02/</td></tr></table>
</body>