logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sicker <boa...@gmail.com>
Subject Re: I'd like to change how the FQCN stuff works in AbstractLogger
Date Wed, 10 Sep 2014 03:21:04 GMT
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 <boards@gmail.com> 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 <remko.popma@gmail.com> 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 <boards@gmail.com> 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 <boards@gmail.com> 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 <remko.popma@gmail.com> 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 <boards@gmail.com> 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 <boards@gmail.com> 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 <boards@gmail.com> 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 <boards@gmail.com>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <boards@gmail.com>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <boards@gmail.com>
>>>>
>>>>
>>>
>>>
>>> --
>>> Matt Sicker <boards@gmail.com>
>>>
>>
>>
>>
>> --
>> Matt Sicker <boards@gmail.com>
>>
>>
>
>
> --
> Matt Sicker <boards@gmail.com>
>



-- 
Matt Sicker <boards@gmail.com>

Mime
View raw message