uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: uima v3 logging
Date Sun, 12 Feb 2017 02:57:15 GMT
On 2/11/2017 6:52 PM, Joern Kottmann wrote:
> Hmm, isn't get getUimaLogger the same as getContext().getLogger() before?
> In my opinion our goal should be to remove that at some point. UIMA is
> easier to use for new users when there is not so much confusion with old
> legacy things around for backward compatibility.
> For your first point about getLogger(), wouldn't this be solved by the MDC?
> The annotator name is always present in the context.
I think there are two ways the annotator name is used in logging.  One is to
provide information (this is what the MDC does, I believe), and the other is to
provide filtering - in that each "named" logger can have a
configured-at-deploy-time-level-spec.  I don't think there is a simple direct
way to say I want to run a particular annotator at "trace" level, for example,
without that annotator name being the name of a logger that you get with

But, maybe I don't fully understand this - logging details are fairly new to me...

If this is true, then you still need to have named loggers in order to filter.
> 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

SLF4j's way of getting loggers is:
Logger.getLogger(String name) or
Logger.getLogger(Class clazz)

They don't have a 0-argument constructor.

> Jörn
> On Fri, Feb 10, 2017 at 4:58 PM, Marshall Schor <msa@schor.com> wrote:
>> Here are differences between getLogger() (now renamed gateUimaLogger()) and
>> LogManager.getLogger() or variants.
>> 1) Every logger is "named".  The no argument version of getLogger()
>> normally
>> defaults this name to the caller's fully qualified class name.
>> For UIMA loggers, this is somewhat different.  It is set to be the
>> Annotator's
>> class name (normally the same thing), but this would be different if the
>> logger
>> is requested from some sub class.
>> 2) The UIMA logger is hooked up to internationalization Resource Bundles,
>> via
>> the UIMA classpath/datapath mechanism.  This hook requires access to the
>> Context to do the resource bundle lookups.
>> If you're not using any of those features, then you can do as you suggest,
>> of
>> course.
>> -Marshall
>> On 2/10/2017 5:46 AM, Joern Kottmann wrote:
>>> I had just read through this quickly. And the one thing that stands out
>>> here for me is the fact,
>>> that you discuss to add some sort of a getLogger method which can be used
>>> by Annotators.
>>> Why would you do that?
>>> If I want to get a logger - and we using log4j2 to in the backend i can
>>> just write LogManager.getLogger()
>>> and I have a logger which will log my messages with MDC (because UIMA
>> will
>>> take care of that for me).
>>> If I have to use some other logger (e.g. forced down on me by
>> dependencies)
>>> I have to deal myself with forwarding that to log4j2,
>>> depending on what is used it might be a matter of the right dependencies
>>> (thinking about slf4j here) or some custom code.
>>> The existing getLogger method should definitely be deprecated and removed
>>> with some later 3.x release.
>>> Jörn
>>> On Mon, Feb 6, 2017 at 9:39 PM, Marshall Schor <msa@schor.com> wrote:
>>>> now considering not using logback except via eclipse plugin dependency,
>> to
>>>> avoid
>>>> license reciprocity issue.
>>>> For normal binary packaging, would use slf4j + some backend, perhaps
>> log4j
>>>> 2.
>>>> These would be "excluded" for the OSGi packaging.
>>>> -Marshall
>>>> On 2/6/2017 3:29 PM, Marshall Schor wrote:
>>>>> I'm trying to think through how to get slf4j to work "nicely" with
>>>> eclipse plugins.
>>>>> Using slf4j, you are supposed to get the benefit of deferring till
>>>> "deploy"
>>>>> time, what back end, and what logging configuration is in use.  We
>> need a
>>>>> solution for non-OSGi and OSGi environments (e.g., Eclipse plugins).
>>>>> For non-OSGi, we have dependencies on slf4j-api; the maven dependencies
>>>> are for
>>>>> slf4j-api + some back end.
>>>>> (Slight twist: for the logback backend, it also provides the slf4j-api
>>>>> implementation, so to use that, you have to "exclude" the slf4j-api JAR
>>>> if it
>>>>> was included).
>>>>> For OSGi, we either need to have a OSGi style dependency, or package
>> the
>>>> runtime
>>>>> with the plugin.  Doing this latter breaks the advantage of being able
>>>> to defer
>>>>> until "deploy" time the particular logging back end.
>>>>> To do the dependency as an OSGi thing, we could (as a default) use the
>>>>> dependency on m2e-slf4j-logback plugin; this comes with m2e as an
>>>> "optional"
>>>>> plugin.  Embedders who wanted alternatives could instead install other
>>>>> components.  See this for background:
>>>>> http://stackoverflow.com/questions/17352485/error-m2e-
>> install-in-eclipse
>>>>>  * for each plugin which might want to depend on slf4j APIs (includes
>>>> "runtime",
>>>>> maybe others)
>>>>>   ** add OSGi dependency on the m2e - slf4j over logback logging (This
>> is
>>>>> installed optionally when you install the m2e support)
>>>>> For non OSGi build/test, some slf4j impl + backend is needed.  I'm
>>>> thinking of
>>>>> also using the logback implementation which has both.
>>>>> For binary packaging: we need to ship something so this works "out of
>>>> the box"
>>>>> but can be substituted.  Again, I'm thinking of using logback
>>>> implementation combo.
>>>>> I'd welcome other informed views, as this is a somewhat new area for
>>>> to think
>>>>> about.
>>>>> -Marshall
>>>>> On 2/2/2017 11:16 AM, Marshall Schor wrote:
>>>>>> Here's a next iteration of set of ideas for logging support in V3.
>>>>>> 1) Keep the v2 uima logging API - so users can migrate at their own
>>>> speed (or
>>>>>> not...)
>>>>>>   - but update the UIMA logger logj4 backend to switch it to log4j-2
>>>>>> 2) Add SLF4j as a "facade" that supports log4j-2, logback and other
>>>> back-end
>>>>>> loggers, configurable at deployment time.
>>>>>>   - Has MDC and NDC (the stack version of MDC) support
>>>>>> https://logback.qos.ch/manual/mdc.html
>>>>>>   - Has support for efficiency and Java 8 styles (e.g. using
>>>> "Supplier<String>"
>>>>>> for messages)
>>>>>>   - Has support for Markers
>>>>>> http://stackoverflow.com/questions/4165558/best-
>>>> practices-for-using-markers-in-slf4j-logback
>>>>>> 3) For Annotators, the base class they extend is augmented with
>>>> getLogger() and
>>>>>> getSlf4jLogger(); these return either the UIMA logger or an SLF4j
>>>> logger with
>>>>>> the name of the Annotator implementation class. getLogger() is just
>>>> shorthand
>>>>>> for the existing getContext().getLogger() api.
>>>>>> 4) Extend the UIMA logger to externalize the hook to UIMA's resource
>>>> bundle
>>>>>> message lookup (which uses the context's ResourceManger's extension
>>>> class loader
>>>>>> if defined), so calls using the slf4j apis can use that if desired.
>>>>>> 5) Update the existing documentation on how to configure backends
>>>> mention slf4j.
>>>>>> 6) A plan to make use of the the slf4j logging in core UIMA.  I'm
>>>> to this,
>>>>>> so please make suggestions for improvement!
>>>>>>   a) Add to MDC: the Annotator being run (probably just the class
>> name)
>>>>>>      There are probably other things that should go into the MDC/NDC,
>>>> but
>>>>>>      I'm not sure what would be useful - suggestions welcome.
>>>>>>   b) Use Markers to identify and control logging related to:
>>>>>>     - annotator (flow-like tracing?)
>>>>>>     - flow_controller
>>>>>>     -  feature structure (creation, updating) - trace-level
>>>>>>         -  index (operations like adding to / removing from)
>>>> -trace-level
>>>>>>         -  index_copy_on_write - trace-level
>>>>>>         - index_auto_rmv_add (when UIMA is automatically removing
>>>> adding
>>>>>> back FSs due to modification of key values) - trace-level
>>>>>>         - serdes (serialization / deserialization)
>>>>>> Please consider this a first try; other suggestions welcome :-)
>>>>>> -Marshall

View raw message