Posted an initial version to JIRA for you all to take a look at.
On 20 April 2014 15:56, Matt Sicker <[email protected]> wrote: > 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]> > -- Matt Sicker <[email protected]>
