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 Mon, 06 Feb 2017 20:39:40 GMT
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.

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 me 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 to mention slf4j.
>> 6) A plan to make use of the the slf4j logging in core UIMA.  I'm new 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 and 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