geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Blum <>
Subject Re: [DISCUSS] log4j errors/warnings
Date Fri, 18 Oct 2019 22:10:00 GMT
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. ...

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 <>

> 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://
>  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.blum10101 (skype)

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