Scratch that (for the jul.LogManager); you can totally abuse reflection to replace the LogManager at runtime!
On 20 April 2014 14:30, Matt Sicker <boa...@gmail.com> wrote: > Speaking of which, that whole "private static final LogManager" is just as > bad as the current "private static final LoggerContextFactory" we've got in > LogManager. This needs to be replaceable after start-up to really be > powerful. > > > On 20 April 2014 13:57, Matt Sicker <boa...@gmail.com> wrote: > >> 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 <ralph.go...@dslextreme.com> 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 <boa...@gmail.com> 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 <boa...@gmail.com> >>> >>> >>> >> >> >> -- >> Matt Sicker <boa...@gmail.com> >> > > > > -- > Matt Sicker <boa...@gmail.com> > -- Matt Sicker <boa...@gmail.com>
