The latest twist: The uima Logger Interface methods are completely disjoint from the SLF4j Logger Interface methods.
So, I've added all of the methods from SLF4j Logger to the UIMA logger. These delegate to the slf4j logger methods. So I think there's no need anymore for both getUimaLogger() and getSlfjLogger() methods. And, if there's no conflict, I'll rename the getUimaLogger() to getLogger() on the Annotator base impl class. If you use the -D option to switch to the log4j logger (in V3, this is the **log4j 2** logger), that logger also implements the slf4j logger's API. Please report any issues you see with this approach :-) -Marshall On 2/14/2017 11:26 AM, Marshall Schor wrote: > hmmm, this is surprising to me, so I'm wondering if some other configuration > of > things might still show some problems. > > Meanwhile, I renamed the core method to getUimaLogger(), which now is nicely > symmetric with getSlf4jLogger(), so I kind of like it. > > And Joern is suggesting we deprecate the uima loggers in favor of more > conventional ones. > Do you have an opinion on this? > > -Marshall > > > On 2/14/2017 6:10 AM, Richard Eckart de Castilho wrote: >> On 06.02.2017, at 19:45, Marshall Schor <[email protected]> wrote: >>> I see the uimaFIT getLogger method is on a class which extends the main UIMA >>> class which would have getLogger(). >>> >>> uimaFIT's method would clash, because it returns a different Java type. >> uimaFIT's ExtendedLogger extends the UIMA Logger. >> >> I have tested adding a getLogger() method to AnalysisComponent_ImplBase in >> UIMA-CORE: >> >> protected Logger getLogger() >> { >> return getContext().getLogger(); >> } >> >> That doesn't seem to clash with the uimaFIT getLogger() declaration: >> >> public ExtendedLogger getLogger() { >> if (logger == null) { >> logger = new ExtendedLogger(getContext()); >> } >> return logger; >> } >> >> where ExtendedLogger implements Logger. >> >> So I guess we could stay with "getLogger()" instead of "getUimaLogger()". >> >> WDYT? >> >> Cheers, >> >> -- Richard >
