geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kirk Lund <kl...@apache.org>
Subject Re: New geode-log4j module
Date Tue, 24 Sep 2019 19:23:59 GMT
It's not a problem in TomcatInstall. Nothing obvious anywhere. Even the
output that GfshRule says is missing the string actually does contain the
missing text. I have no idea why this passed in precheckin but fails now...

On Tue, Sep 24, 2019 at 11:16 AM Kirk Lund <klund@apache.org> wrote:

> 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 <bschuchardt@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 <klund@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 <klund@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 <mhanson@pivotal.io>
>>
>> Let me know if there are any questions or if anyone runs into anything
>> interesting because of these changes.
>>
>>

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