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
