I felt bad about removing the getSlf4jLogger() form, because there is no 0-argument method for getting a slf4j logger.
So, I'm leaning toward keeping it in... The advantage is that it's a quicker/shorter way to get the slf4j logger named for the annotator class implementation name. The log4j equivalent uses some Oracle internal reflection class to get the classname of the caller; I think this defaults to a much slower implementation for non-Oracle JVMs. -Marshall On 2/14/2017 4:31 PM, Marshall Schor wrote: > On 2/14/2017 2:30 PM, Richard Eckart de Castilho wrote: >>> On 14.02.2017, at 17:26, Marshall Schor <[email protected]> wrote: >>> >>> 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? >> Well... I have seen many people not using the UIMA logging framework >> and instead simply fetching a log4j logger or other logging framework >> logger and using that. >> >> I tend to prefer the UIMA logging framework because that means that >> UIMA components use the same logging no matter where they are run. >> It would be annoying if component A would be logging against SLF4J, >> component B logs against JUL, component C logs against commons-logging, >> etc. >> >> SLF4J is by far the framework with which I have had most problems in the >> past mainly because many people don't understand that they should not depend >> on specific backends in their code. >> >> Reflecting the name of a particular external (i.e. non-UIMA) logging >> framework in a UIMA core method leaves me felling a bit uncomfortable. > The only reason I did this was to permit UIMA itself to start adding MDC/NDC > context information that loggers could pick up, as well as Markers. The least > common denominator I found to permit doing that, and not binding a particular > logging back end was slf4j. > >> If we choose to endorse SLF4J, ok - but then I kind of would be with >> Jörn - people can just obtain the logger themselves. The only benefit >> I would see is that channeling people through our on logger factory >> method would provide some control/best practice over the logger >> naming scheme... but that's typically going by the classname anyway. > OK. >> So presently, I would be in favor of dropping "getSlf4jLogger()". >> I could imagine replicating the SLF4J API in the UIMA logging >> framework. Not sure about entirely dropping the UIMA logging >> framework though. > OK. I think I'll keep the old UIMA framework to reduce the friction of having > existing pipelines adopt v3, and to allow a longer on - ramp for converting > (over time, if we desire) UIMA's own use of logging to slf4j + > MDC/NDC/Markers. > > Thanks for your thoughts! -Marshall >> Cheers, >> >> -- Richard >> >> >> >
