Sounds great, Richard! Thanks for taking this one on. Thanks, Jeff
On Tue, Jan 10, 2023 at 9:19 AM Richard Zowalla <r...@apache.org> wrote: > Hi all, > > any additional thoughts? > > At the moment, most people tend towards slf4j (c). > > If there is no other opinion or a hard veto on that code change, I > would like to start working on it and create a related ticket. > > Holiday season just ended but let's give people some more time (maybe > end of next week, 20th January) to order their post holiday mail boxes > ;) > > Gruß > Richard > > > Am Donnerstag, dem 29.12.2022 um 19:01 +0100 schrieb Richard Zowalla: > > Hi all, > > > > thanks Martin and Bruno for your opinions. It is very much > > appreciated! > > > > I think, that we should wait a few more days due to the holiday > > season > > if other people want to express their opinion / thoughts as well. > > > > At the moment it looks like a strong tendency towards C (slf4j) :-) > > > > Happy to hear additional thoughts! > > > > Gruß > > Richard > > > > Am Donnerstag, dem 29.12.2022 um 17:32 +0000 schrieb Bruno P. > > Kinoshita: > > > In Apache Commons when we need to use a logging library, we use JUL > > > as in B) (e.g. Commons Imaging). > > > > > > But higher level code like OpenNLP or Jena, I think it makes more > > > sense C), so +1 for C) (or B) if others prefer, -0 to A)). > > > > > > Thanks! > > > > > > -Bruno > > > > > > On 2022/12/15 10:56:01 Richard Zowalla 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 > > > > > > > > > > > > > > > > > > > > > >
