There's actually a bit of an interesting challenge in converting from a custom level in JUL to Log4j. JUL allows you to use any integer value possible (not just non-negative ones). Also, their progression of level values goes in reverse of ours. Thus, any level above 1000 (Level.SEVERE in JUL) would need to be squeezed into the range of 1 to 99! Plus, Integer.MAX_VALUE indicates StandardLevel.ALL, but Level.OFF in JUL. Then there'd be the other way around, too.
As to those fields, I think we can probably drop them. LogRecord dynamically calculates them from the Throwable stacktrace if necessary. We do it faster. On 9 September 2014 22:07, Matt Sicker <[email protected]> wrote: > What about the logp, entering, exiting, and throwing methods which all > take a source class name and a source method name? Just ignore them? > > On 9 September 2014 21:40, Remko Popma <[email protected]> wrote: > >> My take would be to drop the seqNo and threadID integer, and for level, >> check if its a built-in JUL level which can be translated to a built-in >> log4j level. If it's not a built-in JUL level we can do a log4j >> Level.forName() call to create that custom level in log4j as well. >> Thoughts? >> >> Sent from my iPhone >> >> On 2014/09/10, at 11:07, Matt Sicker <[email protected]> wrote: >> >> I'm actually thinking of some sort of LogRecordMessage or similar which >> takes a useful subset of LogRecord. >> >> On 9 September 2014 21:01, Matt Sicker <[email protected]> wrote: >> >>> 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]> >>> >> >> >> >> -- >> Matt Sicker <[email protected]> >> >> > > > -- > Matt Sicker <[email protected]> > -- Matt Sicker <[email protected]>
