Something for 2.1? Sent from my iPhone
> On 2014/04/21, at 5:45, Matt Sicker <[email protected]> wrote: > > 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 <[email protected]> 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 <[email protected]> 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 <[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]> >> >> >> >> -- >> Matt Sicker <[email protected]> > > > > -- > Matt Sicker <[email protected]>
