At this point, I'm starting to think so. I'm trying to implement this using the proper security contexts and such, and I'm already writing a new reflection utility class.
On 20 April 2014 15:43, Remko Popma <[email protected]> wrote: > 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]> > > -- Matt Sicker <[email protected]>
