Looking into what to do for UIMA v3 logging. Some things I'm learning: - When UIMA is used as part of bigger applications, those apps frequently specify a particular logging implementation and strategy, to which the information logged by UIMA should conform.
- Java 8 lambda allows deferring expensive computation of logged values -- a more compact way than guarding each log statement with an if (log-xxx-level-is-enabled...) - SLF4j seems to be the best logging "facade". It allows switching of actual logging implementation at deploy time - logback (an implementation) is the next generation beyond log4j - UIMA implements its own facade, that can be mapped to 3 impls: -- log4j -- native-java-logger (called JSR47logger) -- a non-framework, only minimally configurable, not documented, and probably not-used implementation that writes to some standard output places - uimaFIT has an internal (package) class that extends the base UIMA APIs with a few of the SLF4j apis. - New logging facilities available via SLF4j and supported by logback include -- MDC (Mapped Diagnostic Contexts), having 1 instance per thread -- Markers (discussed here: http://stackoverflow.com/questions/4165558/best-practices-for-using-markers-in-slf4j-logback My first impression of all this for UIMA v3 is 3 main ideas: 1) keep the current UIMA logging facade and framework, for backwards compatibility. 2) add the SLF4J facade (which includes support for Java 8 lambdas as arguments), and instructions on how to configure logback and other implementations. 3) add some standard MDC and Markers - these need to be architected for "common" use cases for UIMA logging, in ways that won't conflict with users. Other views/opinions? -Marshall
