You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@opennlp.apache.org by Richard Zowalla <rz...@apache.org> on 2022/12/15 10:56:01 UTC
Logging in OpenNLP
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
Re: Logging in OpenNLP
Posted by Richard Zowalla <rz...@apache.org>.
Site-notes:
- The UIMA component already pulls in SLF4J API (1.7.36).
- If we decide to use a listener / handler / facade-based approach, we
need to ensure, that it is possible for logging framework users to
retrieve related context information (caller class, calling method,
line numbers, ...) otherwise it wouldn't be much gain in terms of user-
friendlyness imho.
Happy to hear other opinions about logging in OpenNLP.
Gruß
Richard
Am Montag, dem 19.12.2022 um 14:46 -0500 schrieb Jeff Zemerick:
> 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 <rz...@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
> >
> >
> >
> >
> >
Re: Logging in OpenNLP
Posted by Martin Wiesner <ma...@apache.org>.
Hi all,
I favor option C, as proposed by @rzo1 - IMHO, slf4j-api is lightweight enough and offers many benefits for users which want to choose a logger implementation or adapt to the needs of their specific execution environment.
+1 option "C"
Best
Martin
--
https://twitter.com/mawiesne
On 2022/12/28 11:19:11 Richard Zowalla wrote:
> Hi,
>
> any other opinions about it? :-)
>
> My personal view would also to switch to SLF4J (Option C), so OpenNLP
> can be easiliy integrated and logging just works out of the box
> (instead of relying on System.out calls).
>
> JUL is a bit of a pain to configure, but works, if it is done
> correctly. That would be my second choice, if we want to stick at the
> "minimal deps" credo.
>
> Side note: We even have some (evil) call to System.setOut(...) in
> OpenNLP, which likely interfer if OpenNLP is used as a library (and
> which isn't something exepected from a user point of view). We can
> maintain the principle of "minimal deps", if we only ship a logging
> implementation + config in the dist package. All other locations can
> either be "test" or "optional=true". We just need to document, that
> integrators need to provide a logging implementation + ensure, that CLI
> users doesn't notice the switch.
>
> Gruß
> Richard (the other one ;-) )
>
> Am Mittwoch, dem 21.12.2022 um 08:03 +0100 schrieb Richard Eckart de
> Castilho:
> > Hi,
> >
> > > On 19. Dec 2022, at 20:46, Jeff Zemerick <jz...@apache.org>
> > > wrote:
> > >
> > > 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.
> >
> > for history reasons, Apache UIMA has its own logging API which in
> > newer versions incorporates the SLF4J API ... but the UIMA logging
> > API still first talks to its own delegation layer which then can
> > delegate to SLF4J or talk directly to Log4J or other implementations.
> >
> > As I said: this is a historic thing. But having had to fix bugs in
> > the delegation layer, I can tell you that it is not a fun thing at
> > all to have to maintain that delegation layer. In the latest round of
> > fixes I even had to resort to using reflection to access methods that
> > Log4J chose to no longer make public in its latest release to ensure
> > the delegation layer still works. Yuck!
> >
> > +1 for option C: just use the SLF4J API directly.
> >
> > Cheers,
> >
> > -- Richard (from Apache UIMA)
> >
>
>
Re: Logging in OpenNLP
Posted by Richard Zowalla <rz...@apache.org>.
Hi,
any other opinions about it? :-)
My personal view would also to switch to SLF4J (Option C), so OpenNLP
can be easiliy integrated and logging just works out of the box
(instead of relying on System.out calls).
JUL is a bit of a pain to configure, but works, if it is done
correctly. That would be my second choice, if we want to stick at the
"minimal deps" credo.
Side note: We even have some (evil) call to System.setOut(...) in
OpenNLP, which likely interfer if OpenNLP is used as a library (and
which isn't something exepected from a user point of view). We can
maintain the principle of "minimal deps", if we only ship a logging
implementation + config in the dist package. All other locations can
either be "test" or "optional=true". We just need to document, that
integrators need to provide a logging implementation + ensure, that CLI
users doesn't notice the switch.
Gruß
Richard (the other one ;-) )
Am Mittwoch, dem 21.12.2022 um 08:03 +0100 schrieb Richard Eckart de
Castilho:
> Hi,
>
> > On 19. Dec 2022, at 20:46, Jeff Zemerick <jz...@apache.org>
> > wrote:
> >
> > 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.
>
> for history reasons, Apache UIMA has its own logging API which in
> newer versions incorporates the SLF4J API ... but the UIMA logging
> API still first talks to its own delegation layer which then can
> delegate to SLF4J or talk directly to Log4J or other implementations.
>
> As I said: this is a historic thing. But having had to fix bugs in
> the delegation layer, I can tell you that it is not a fun thing at
> all to have to maintain that delegation layer. In the latest round of
> fixes I even had to resort to using reflection to access methods that
> Log4J chose to no longer make public in its latest release to ensure
> the delegation layer still works. Yuck!
>
> +1 for option C: just use the SLF4J API directly.
>
> Cheers,
>
> -- Richard (from Apache UIMA)
>
Re: Logging in OpenNLP
Posted by Richard Eckart de Castilho <re...@apache.org>.
Hi,
> On 19. Dec 2022, at 20:46, Jeff Zemerick <jz...@apache.org> wrote:
>
> 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.
for history reasons, Apache UIMA has its own logging API which in newer versions incorporates the SLF4J API ... but the UIMA logging API still first talks to its own delegation layer which then can delegate to SLF4J or talk directly to Log4J or other implementations.
As I said: this is a historic thing. But having had to fix bugs in the delegation layer, I can tell you that it is not a fun thing at all to have to maintain that delegation layer. In the latest round of fixes I even had to resort to using reflection to access methods that Log4J chose to no longer make public in its latest release to ensure the delegation layer still works. Yuck!
+1 for option C: just use the SLF4J API directly.
Cheers,
-- Richard (from Apache UIMA)
Re: Logging in OpenNLP
Posted by Jeff Zemerick <jz...@apache.org>.
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 <rz...@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
>
>
>
>
>
Re: Logging in OpenNLP
Posted by Richard Zowalla <rz...@apache.org>.
Here it is: https://issues.apache.org/jira/browse/OPENNLP-1447
Am Mittwoch, dem 11.01.2023 um 10:20 -0500 schrieb Jeff Zemerick:
> Sounds great, Richard! Thanks for taking this one on.
>
> Thanks,
> Jeff
>
> On Tue, Jan 10, 2023 at 9:19 AM Richard Zowalla <rz...@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
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
Re: Logging in OpenNLP
Posted by Jeff Zemerick <jz...@apache.org>.
Sounds great, Richard! Thanks for taking this one on.
Thanks,
Jeff
On Tue, Jan 10, 2023 at 9:19 AM Richard Zowalla <rz...@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
> > > >
> > > >
> > > >
> > > >
> > > >
>
>
Re: Logging in OpenNLP
Posted by Richard Zowalla <rz...@apache.org>.
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
> > >
> > >
> > >
> > >
> > >
Re: Logging in OpenNLP
Posted by Richard Zowalla <rz...@apache.org>.
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
> >
> >
> >
> >
> >
Re: Logging in OpenNLP
Posted by "Bruno P. Kinoshita" <ki...@apache.org>.
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
>
>
>
>
>