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