Thanks for bringing this to the mailing list, Richard. I think your findings from digging into the history are accurate.
Of your given options, which seem comprehensive, I think my preference is option D, followed by C, but I'm very interested in what others think. With option D, if we implement the listeners we can have it default to System.out and have the same behavior as it is currently implemented, while giving the user the ability to use a different logging mechanism if needed. Users who use the CLI tools will still have logs to System.out, and users who implement OpenNLP as a library can provide their own logging. It seems this would also allow us to maintain the principle of minimizing external dependencies. For C, having minimal dependencies is a good idea in general but I think it gets to a point where it can be hard when you want your library to play well with others. I don't think I would object to an SLF4J dependency if the community wants to go in that direction. Thanks, Jeff On Thu, Dec 15, 2022 at 5:56 AM Richard Zowalla <r...@apache.org> wrote: > Hi all, > > I wanted to start a discussion regarding logging / sysout in OpenNLP > based on the discussion raised in a recent PR [1]. > > From my digging into the history of OpenNLP developmen, I found [2] and > [3] (~ 7 years) ago with an (unsuccessful) attempt to switch to a > logging implementation as "the project has always tried to maintain a > principle of using the fewest dependencies as possible." > > 7 years later I want to start this discussion (this time _on_ the list) > again and discuss possibile ways of introduce proper logging and > collect pros/cons for solutions, which can include the option of let it > be like it is ;) > > Problem statement: > > There seems to be no concept of logging used in OpenNLP. We have > various classes, which make use of System.out.println(...) or > System.err.println(...). There is no central concept of logging. Most > of these statements are related to DEBUG or are used to INFOrm the > user, that something went wrong or something is done. > > This makes it awkward to use the modules and integrate it into > different application (as it spams our logs (if someone redirects > System.out or console) or is lost as the modules are used within an > application server, etc.) > > Ideas: > > From my point of view, we have several ways / options to deal with it: > > (A) We leave it as is and don't touch it. > > (B) We switch to java.util.logging (JUL) (no additional deps, might be > a bit akward to use) and provide some bridging adapters / modules / > examples to hook a user logging library (log4j2, logback, ...) and > handle JUL from a user point of view. Of course, this would require to > provide some basic config (similar to System.out) to ship with the CLI > tools. > > (C) We use a common logging api like SLF4J and deal with that in our > code base. We include no dependency to any logging implementation (only > in "test" scope) and let the user choose a concrete logging > implementation for their own purpose. However, if OpenNLP is used as a > CLI, we need to ship a dependency towards a logging library to make it > work + configuration. This might possibily require to split the cli / > tools module. > > (D) We could implement some sort of listener construct and delegate > System.out calls to that layer. Users could change the way the listener > deals with the System.out messages. Problem: Context (Method, Class, > ...) in the calltrace might be lost (if needed) > > (E) Any other ideas? > > That said, I am fairly new in the OpenNLP community and appreciate any > feedback / ideas on that topic. If we - as a communtity - that we don't > want to deal with logging frameworks, so be it :) > > Thanks for feedback & Gruß > Richard > > > [1] https://github.com/apache/opennlp/pull/456#discussion_r1045816514 > [2] https://issues.apache.org/jira/browse/OPENNLP-675 > [3] https://github.com/apache/opennlp/pull/5 > > > > >
