> 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. 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. 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. Cheers, -- Richard
