Well, looking at the LogManager source, I see what you're saying. The global LogManager instance is a private static final field, so even with reflection, you can't override that. So yes, you'd have to set the system property before LogManager gets initialized, or it would need to be user-specified.
When it comes to improving the SLF4J bridge, I think we could include support for converting JDK Level names to markers as a neat addition. Also, I think a possible solution would be to implement a custom LogManager, add documentation to the effect that you need to set that system property to use it, and do some reflection on startup to see if we're using the custom LogManager. If we're using a different one, we can just set the root logger's handlers like the slf4j-jdk14 class does. I'll work on a proof of concept and see how feasible this is. On 20 April 2014 13:24, Ralph Goers <[email protected]> wrote: > I’ve answered this before and it always starts with "java.util.logging > sucks” - at least from the point of view of trying to use its API on top of > something else. (It sucks in other ways too but that is a different > discussion). > > Take a look at the LogManager class. The only way to replace the JDK > LogManager is via a system property. I could swear I tried to do this once > and came to the conclusion that the only sane way to create a bridge was to > do what SLF4J does, and I don’t see the point of creating code that does > the exact same thing in exactly the same way. > > That said, if you can come up with a better way to implement the bridge I > am all for it. > > Ralph > > > > > > On Apr 20, 2014, at 11:00 AM, Matt Sicker <[email protected]> wrote: > > I know that the documentation says to use the slf4j JUL bridge, but that > seems excessive. Is there any reason we don't have our own bridge? Or is it > just a better idea to use the slf4j one? > > -- > Matt Sicker <[email protected]> > > > -- Matt Sicker <[email protected]>
