Great writeup, thanks for sharing Kirk! Anthony
> On Sep 24, 2019, at 10:24 AM, Kirk Lund <kl...@apache.org> wrote: > > All classes that use *log4j-core* have now moved to the new module > *geode-log4j > *on develop. The default log4j2.xml configuration file for Geode Locators > and Servers has also moved to geode-log4j. > > The first Geode release expected to include this change is 1.11.0. > > The geode-log4j module is included in geode-dependencies.jar so that > Locators and Servers will continue to use the code and configuration in > geode-log4j by default. It is also included in the classpath of most > *integrationTest* and *distributedTest* targets to facilitate non-unit test > debugging, support *dunit grep for suspect strings*, and also to avoid > moving or changing tests that involve or require Geode Alerting or Logging > functionality. > > Precheckin was GREEN before merging to develop, so all Geode tests should > be unaffected. > > *A. The effects of not having geode-log4j on the classpath > (client/server/locator) are:* > > 1) Log4j will not be configurable by Geode > > 2) Log4j will print out an error message if not configured by User or Geode > > This is printed out by Apache Log4j (not by Geode): > > 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. See > https://logging.apache.org/log4j/2.x/manual/configuration.html for > instructions on how to configure Log4j 2 > > 3) Geode will not create a log file by default (when starting a server or > locator using GFSH) > > 4) Logging configuration properties do nothing > > Logging configuration properties include: > * log-disk-space-limit > * log-file > * log-file-size-limit > * log-level > > 5) Geode Alerts will never be generated > > Geode Alerts are exposed primarily exposed via: > * DistributedSystemMXBean JMX Notifications > * Viewable in Pulse (via DistributedSystemMXBean) > * (Deprecated) Admin API support for Alert Listening > > 6) GFSH commands or options involving Logging and Alerting do nothing > > GFSH commands or options involving Logging and Alerting: > * alter runtime (log-disk-space-limit, log-file, log-file-size-limit, > log-level) > * export logs > * show log > * start locator (log-level, redirect-output) > * start server (log-level, redirect-output) > > *B. The primary reasons a user might not include geode-log4j in their > classpath:* > > a) User wants to use Logback or other backend instead of log4j-core > (especially true for users of Spring Boot) > > b) User wants greater control over logging, especially in a client or > embedded application > > Since Geode uses log4j-api Loggers for its internal logging, swapping out > log4j-core for logback as the backend imposes a significant performance > penalty. Although, the logging APIs and backends are interchangeable, using > the intended backend with its matching API provides the best performance > for both log4j-api/log4j-core and slf4j/logback. > > *C. Impact on IDE usage* > > IntelliJ projects for Geode should automatically pull in geode-log4j when > it re-imports from gradle. Note that may see warnings about *"**No Log4j 2 > configuration file found.**"* if you're running a test that doesn't have > geode-log4j on its classpath. > > For more advanced projects in IntelliJ with additional non-Geode modules, > you might benefit from using *-Dclasspath* (or other > proprietary/environment options) in *Gradle VM options*. > > The commit on develop: > > commit efc2362d2bae0877a427ce2c29beae94118d6567 > Author: Kirk Lund <kl...@apache.org> > Date: Thu Aug 8 15:17:54 2019 -0700 > > GEODE-6964: Move geode log4j core classes to geode-log4j > > Introduce new Logging and Alerting SPIs. Extract all log4j-core code to > geode-log4j module. > > The geode-core module no longer contains log4j2.xml and no longer has a > dependency on log4j-core. > > All code that uses log4j-core has moved to the new module geode-log4j. > The log4j2.xml for Geode now lives in geode-log4j as well. These > changes ensure that users have better control over logging including > which backend to use. This should improve user experience when using > Spring Boot. > > Co-authored-by: Mark Hanson <mhan...@pivotal.io> > > Let me know if there are any questions or if anyone runs into anything > interesting because of these changes.
