On 1/29/2017 10:47 AM, Richard Eckart de Castilho wrote: > On 24.01.2017, at 21:48, Marshall Schor <[email protected]> wrote: >> 1) keep the current UIMA logging facade and framework, for backwards >> compatibility. > uimaFIT adds a getLogger() method to its base-classes for reader and engines > because > getting the logger via the context is just an extra step > (getContext().getLogger().error(...) vs > getLogger().error(...)). I like adding this to the uima component base classes; thanks for the suggestion. > > It could be considered adding logging methods directly to the UIMA component > base-classes, such > that one simply would call "error(...)"? Or introducing a short getter method > (log().error(...)))? Not so sure about this, mainly because the log4j APIs are large. For example, from the log4j-api, to get a logger, there are (excluding deprecated) - 4 APIs for getting a formatterLogger (one that lets you use format strings) - 9 APIs for getting a logger and once you have a logger, there are methods for all the levels: - debug, error, fatal, info, trace, warn - plus log itself, - plus "flow-event" calls: throwing, catching, traceEntry, traceExit and for each of the main kinds (e.g. warn, info, etc.) there are 23 varieties, (excluding the ones with 1, 2, ... 9 parameters).
If someone can figure out a good way to subset this down to the "essential set" mostly used, maybe we could do that. -Marshall > Cheers, > > -- Richard
