You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Bruce Schuchardt <bs...@pivotal.io> on 2019/10/18 20:26:48 UTC
[DISCUSS] log4j errors/warnings
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?
Re: [DISCUSS] log4j errors/warnings
Posted by Kirk Lund <kl...@apache.org>.
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 <jb...@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 <gz...@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 <kl...@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 <jb...@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)
>
Re: [DISCUSS] log4j errors/warnings
Posted by Kirk Lund <kl...@apache.org>.
Just to be clear... this does NOT cause any precheckin or CI failures. It's
just noise caused by log4j-api nagging about the lack of a backend.
On Tue, Oct 22, 2019 at 11:33 AM Xiaojian Zhou <gz...@pivotal.io> wrote:
> In CI, I keep hitting "> Task :geode-assembly:defaultCacheConfig
>
> 09:13:37 <
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-pr/jobs/DistributedTestOpenJDK11/builds/4572#L5d9757af:547
> >
> ERROR StatusLogger Log4j2 could not find a logging implementation.
> Please add log4j-core to the classpath. Using SimpleLogger to log to
> the console..."
>
>
> On Tue, Oct 22, 2019 at 11:31 AM John Blum <jb...@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 <gz...@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 <kl...@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 <jb...@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)
> >
>
Re: [DISCUSS] log4j errors/warnings
Posted by Xiaojian Zhou <gz...@pivotal.io>.
In CI, I keep hitting "> Task :geode-assembly:defaultCacheConfig
09:13:37 <https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-pr/jobs/DistributedTestOpenJDK11/builds/4572#L5d9757af:547>
ERROR StatusLogger Log4j2 could not find a logging implementation.
Please add log4j-core to the classpath. Using SimpleLogger to log to
the console..."
On Tue, Oct 22, 2019 at 11:31 AM John Blum <jb...@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 <gz...@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 <kl...@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 <jb...@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)
>
Re: [DISCUSS] log4j errors/warnings
Posted by John Blum <jb...@pivotal.io>.
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 <gz...@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 <kl...@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 <jb...@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)
Re: [DISCUSS] log4j errors/warnings
Posted by Xiaojian Zhou <gz...@pivotal.io>.
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 <kl...@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 <jb...@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)
> >
>
Re: [DISCUSS] log4j errors/warnings
Posted by Kirk Lund <kl...@apache.org>.
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 <jb...@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 <bs...@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)
>
Re: [DISCUSS] log4j errors/warnings
Posted by John Blum <jb...@pivotal.io>.
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 <bs...@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)