I've got ranges in place to map to standard levels, but custom level support is currently done through the MDC. Should I use a MapMessage instead? Make a new Message type just for log4j-jul? There's metadata in some of these Logger methods that I'd like to include, but if the MDC isn't the best way to do that, then I'd prefer another way. I noticed that pax-logging does this for every log event to include some metadata about the OSGi bundle that made the log call, so I kept up the style.
As to the static field, yes, I noticed that, too. It's only for a sequence number, and we have our own (better) way of doing that with on-demand sequencing (and using the AtomicXxx classes indeed) anyways. On 9 September 2014 20:39, Remko Popma <[email protected]> wrote: > Fro a performance point of view, it would be great if we could avoid > creating LogRecord instances. Not just from a GC perspective, but in java6 > the LogRecord constructor synchronizes on a static variable(!): big > bottleneck. This is improved (using AtomicXxx) in java7. > > Also would great if we can avoid using the ThreadContext MDC for every log > event. (Its copy-on-write design is not a good match for this usage...) > > Would there be a way to map custom JUL log levels to custom Log4j levels? > > Sent from my iPhone > > On 2014/09/10, at 10:20, Matt Sicker <[email protected]> wrote: > > Actually, now that I look at it, I can just use an inner class with > ExtendedLoggerWrapper to get at those protected methods I mentioned. I > mean, that appears to be the point of it! Let me see if it does everything > I needed. > > On 9 September 2014 20:08, Matt Sicker <[email protected]> wrote: > >> Now that I'm looking at this, what's the point of all the methods that >> take a FQCN instead of having just the ones in ExtendedLogger? I'm not sure >> why we didn't just use a field in AbstractLogger in the first place. >> >> On 9 September 2014 19:14, Matt Sicker <[email protected]> wrote: >> >>> I'm making some changes to log4j-jul to reduce redundant time spent >>> constructing a LogRecord that I don't even want to use most of the time. >>> However, the ExtendedLogger interface (which I need to use at the very >>> least so that I can set the fqcn to java.util.logging.Logger) only provides >>> a single version of logMessage (unlike AbstractLogger which has a bunch), >>> and several methods like catching(), throwing(), etc., all depend on >>> protected methods in AbstractLogger that I'd rather not re-implement. It >>> would be nice if I could just call the Logger methods I need, but they all >>> get called with the wrong fqcn. >>> >>> Can we use a non-static final field that contains the fqcn? If I could, >>> I'd extend AbstractLogger myself, but I already have to extend the JUL >>> Logger class (should have been an interface, grrr). Thus, I can't rely on >>> AbstractLogger being the source of all these method calls. Unlike the other >>> adapters, JUL provides more various logger calls than we even have, and I >>> don't think ExtendedLogger was written with this scenario in mind. >>> >>> I don't think this should be too large an impact of a change. I'm going >>> to push up a proposal, but feel free to veto it or offer some suggestions! >>> >>> -- >>> Matt Sicker <[email protected]> >>> >> >> >> >> -- >> Matt Sicker <[email protected]> >> > > > > -- > Matt Sicker <[email protected]> > > -- Matt Sicker <[email protected]>
