I understand your sentiment. I remember being very disappointed at how jul works under the hood.
All right, so that diagram will go: [App + JUL] -> jul-to-slf4j -> slf4j-impl -> log4j-2.0-api -> log4j-2.0-core Thanks! Sent from my iPhone (Msg below truncated to prevent rejection...) On 2013/07/21, at 16:16, Ralph Goers <[email protected]> wrote: > <rant> > First, I have to state that java.util.logging absolutely sucks. Ceki once > mentioned that the guys who did the JCR asked him for advice. From what I > can tell they took his advice and did exactly the opposite. While the API > isn't horrible, the implementation is very primitive. But the worst part is > that to hook in your own implementation you have to set a system property - > and even that doesn't really work. Unfortunately, JUL was created before > ServiceLoader existed and it has never been improved to allow for it. But > the worst part is that the Sun LogManager class does a new on > LogManager.RootLogger to create the root Logger and doesn't even delegate its > creation to the delegated LogManager, which makes it impossible to use Log4j > for the root logger. So the only other option is to hook into JUL as a > Handler, which is what SLF4J does. > </rant> > > After all of that I looked at jul-to-slf4j and even though I hate the way it > works I came to the conclusion we weren't going to do much better. I couldn't > bring myself to just reimplement that on top of the Log4j API and since the > performance pretty much sucks anyway that user's should just use it and route > SLF4J to Log4j 2. > > FWIW, Gary asked about this last November and I gave him a similar answer, > although at the time I had not looked into actually creating an > implementation so I didn't know about the challenges of creating your own > LogManager.. > > Ralph >
