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 > >
