geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kirk Lund <kl...@apache.org>
Subject Re: [DISCUSS] log4j errors/warnings
Date Tue, 22 Oct 2019 19:04:33 GMT
Note: John's suggestions are some really good alternatives to consider
instead of adding log4j-core to the unit testing classpaths.

On Tue, Oct 22, 2019 at 11:31 AM John Blum <jblum@pivotal.io> wrote:

> There are other ways of controlling the Log4j2 Status Logger other than
> adding test dependencies.
>
>
> For instance, you can:
>
> 1. Set the JVM System property
> org.apache.logging.log4j.simplelog.StatusLogger.level to "OFF".
>
> 2. Theoretically, when Lo4j2 finds a log4j2 or log4j2-test Properties,
> YAML, JSON or XML file on the classpath, it should honor the following
> configuration setting, e.g. in log4j2.xml:
>
> <Configuration status="OFF">
>
> This is described in the Log4j documentation at
> https://logging.apache.org/log4j/2.x/manual/configuration.html in
> section "*Status
> Messages*".
>
> Also see the section "*Automatic Configuration*" for more details on how
> Log4j2 resolves configuration metadata (e.g. log4j2.xml).
>
> 3. There are also programmatical ways to control status logging by
> acquiring the StatusLogger and removing all StatusListeners prior to the
> Log4j2 logging system being initialized, or alternatively setting a no-op
> StatusListener implementation, which you would need to implement yourself
> since, seemingly, *Log4j2* does not provide an implementation unlike
> *Logback*. (e.g. [1])
>
> StatusLogger.getLogger().getListeners().forEach(StatusLogger.getLogger
> ()::removeListener);
>
>
> Quickly experimenting, the only approach I got working in my *Spring Boot*
> application using Apache Geode was #1.  I suspect there was other things
> running interference, but I did not investigate further.
>
> Anyway, I would error on the side of caution and use 1 of the approaches
> above rather than simply throwing in another dependency, testRuntime or
> otherwise.  It is too easy for that to be inadvertently and incorrectly
> changed by some maintainer later on.
>
> $0.02
>
> -j
>
>
> [1]
>
> https://github.com/spring-projects/spring-boot-data-geode/blob/master/spring-geode-docs/src/main/resources/logback.xml#L4
>
>
> On Tue, Oct 22, 2019 at 9:57 AM Xiaojian Zhou <gzhou@pivotal.io> wrote:
>
> > I hit this problem in PR. I am just curious why it did not happen before?
> >
> >
> > On Tue, Oct 22, 2019 at 9:44 AM Kirk Lund <klund@apache.org> wrote:
> >
> > > I'm ok with adding log4j-core to the testRuntime for all unit test
> > targets
> > > to prevent the ERROR message. Any other input?
> > >
> > > On Fri, Oct 18, 2019 at 3:10 PM John Blum <jblum@pivotal.io> wrote:
> > >
> > > > Be careful to only add logging dependencies as testRuntime
> > dependencies.
> > > > Do not add any logger implementation/provider (e.g. log4j-core, or
> > > > otherwise) in either the compile-time or runtime scope.
> > > >
> > > > This also means that when users are using and running Apache Geode
> > > > applications (regardless of context), they will need to explicitly
> > choose
> > > > and declare a logging implementation, otherwise they will see the
> same
> > > > ERROR message logged.  For example, when using Spring Boot, users
> > > > would declare a runtime dependency on
> > > > org.springframework.boot:spring-boot-starter-logging.  This uses
> > Logback
> > > as
> > > > the logging provider and adapts Log4j with SLF4J using the bridge.
> > > >
> > > > To make matters worse, unfortunately, this message is logged by the
> > > logging
> > > > facade as an error when it should rather be logged as WARN instead,
> or
> > > > arguably less.
> > > >
> > > > Technically, you should also be able to quiet down the "internal"
> > Logging
> > > > facade messaging using a no-op status listener, e.g. ...
> > > >
> > > >
> > > >
> > >
> >
> https://github.com/spring-projects/spring-boot-data-geode/blob/master/spring-geode-tests/smoke-tests/spring-initializer/src/test/resources/logback.xml#L4
> > > >
> > > > I not sure what that is for Log4j2 (but there should be an
> equivalent).
> > > >
> > > >
> > > >
> > > > On Fri, Oct 18, 2019 at 1:26 PM Bruce Schuchardt <
> > bschuchardt@pivotal.io
> > > >
> > > > wrote:
> > > >
> > > > > Not long ago changes were made to the sub-projects that introduced
> a
> > > lot
> > > > > of build noise.  In gradle builds we see a lot of this:
> > > > >
> > > > > ERROR StatusLogger Log4j2 could not find a logging implementation.
> > > Please
> > > > > add log4j-core to the classpath. Using SimpleLogger to log to the
> > > > console...
> > > > >
> > > > > and in IntelliJ unit test runs we get this:
> > > > >
> > > > > ERROR StatusLogger No Log4j 2 configuration file found. Using
> default
> > > > > configuration (logging only errors to the console), or user
> > > > > programmatically provided configurations. Set system property
> > > > > 'log4j2.debug' to show Log4j 2 internal initialization logging.
> > > > Seehttps://
> > > > > logging.apache.org/log4j/2.x/manual/configuration.html  for
> > > instructions
> > > > > on how to configure Log4j 2
> > > > >
> > > > > That's really annoying and it looks like Geode is broken.  To fix
> > this
> > > > > it was suggested that "we would have to add log4j-core to the
> > classpath
> > > > > of unit tests to get log4j-api to stop complaining".
> > > > >
> > > > > I think this should be done.  Any objections?
> > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > -John
> > > > john.blum10101 (skype)
> > > >
> > >
> >
>
>
> --
> -John
> john.blum10101 (skype)
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message