On 2/12/2017 5:36 AM, Joern Kottmann wrote:

... snip ...
> Lets says we write the annotator name into the mdc. In that case log4j2 can
> use the ThreadContextMapFilter to filter log messages based on properties
> in the mdc.
>
> Have a look here:
> https://logging.apache.org/log4j/2.x/manual/filters.html
>
Good point, I had forgotten this.  It looks to be fairly efficient, too.

>
>>> The user will have a hard time making use of that in more serious
>>> applications. It would be awkward to pass the logger reference to other
>>> classes and dependencies might just log directly to our logger backend.
>> I agree.  There's a kind of work around for the use case where an Annotator
>> (which would have a named logger) calls other code, perhaps deeply nested,
>> and
>> somewhere deep down, that code wants to log something.  If it wants to log
>> using
>> the Uima Logger, it could by using the call
>> UimaContextHolder.getContext().getLogger()
>>
>> SLF4j's way of getting loggers is:
>> Logger.getLogger(String name) or
>> Logger.getLogger(Class clazz)
>>
>> They don't have a 0-argument constructor.
>>
>>
> Maybe I am wrong here but I really don't think it is important that
> annotator name is the same as the logger name, because the annotator name
> should always be in the mdc.
That's true.  The purpose of having named loggers is only to divide the 1000's
of logging statements (I'm being very optimistic here :-) ) into sub groups
where you can enable / disable each group separately in the configuration, at
different levels, etc.

Of course, the MDC/NDC setting hasn't yet been implemented - yet - in UIMA. 
I'll add a jira for this :-).

The convention (and it's only a convention) is to name the logger to be the same
name as the fully qualified class name where the log statement is. 

UIMA was only trying to follow the popular convention of naming loggers in this
manner. 
> This should work out of the box until the user starts his own threads
> (because then the mdc will be empty).
Actually, that's also controllable, for log4j, by setting the system property
"isTreadContextMapInheritable" to "true".
https://logging.apache.org/log4j/2.x/manual/thread-context.html - scan down to
near the bottom "Implementation details".

-Marshall

Reply via email to