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 < > > bschucha...@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) >
