ConnectCommandAcceptanceTest is now failing on develop. Looks like the test
is using Geode 1.3.0 (not sure why).
It also looks like my commit and the following commit didn't merge properly
despite not having any conflicts. Looking into how to fix it now.
It's possible that GEODE-7168 removed geode-log4j from the Tomcat
classpath...
commit a0f7a0f041c47830053b0fd1c8d9c4e51fb9a058
Author: Bruce Schuchardt <bschucha...@pivotal.io>
Date: Wed Sep 11 15:49:35 2019 -0700
GEODE-7168 tomcat rolling upgrade test failure
This PR reinstates the changes to this test and modifies the
geode-old-versions subproject to preserve the full version string (with
periods) for older versions. This lets the tomcat test build a
classpath without requiring the target version to have representation in
Version.java.
On Tue, 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.
>
>
