[
https://issues.apache.org/jira/browse/GEODE-6964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund resolved GEODE-6964.
------------------------------
Fix Version/s: 1.11.0
Resolution: Fixed
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 {color:#57D9A3}GREEN{color} 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):
{noformat}
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
{noformat}
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:
{noformat}
commit efc2362d2bae0877a427ce2c29beae94118d6567
Author: Kirk Lund <[email protected]>
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 <[email protected]>
{noformat}
Let me know if there are any questions or if anyone runs into anything
interesting because of these changes.
> Log4j configuration can be altered by adding geode-core to the classpath
> ------------------------------------------------------------------------
>
> Key: GEODE-6964
> URL: https://issues.apache.org/jira/browse/GEODE-6964
> Project: Geode
> Issue Type: Bug
> Components: logging
> Affects Versions: 1.0.0-incubating, 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1,
> 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0, 1.9.1, 1.10.0
> Reporter: Stephane Nicoll
> Assignee: Kirk Lund
> Priority: Major
> Fix For: 1.11.0
>
> Time Spent: 20h
> Remaining Estimate: 0h
>
> {{geode-core}} ships with a {{log4j2.xml}} at the standard location which
> means that it is a candidate for bootstraping the logging infrastructure of
> any app using that library. See also #GEODE-189
> This is a problem when embedding this library in application that relies on
> the absence of such a file to derive a sensible default configuration
> (typically a Spring Boot app).
> In general, the hard dependency on log4j is a bit annoying for the embedded
> use case. There is more context available here:
> https://github.com/spring-projects/spring-boot-data-geode/issues/42
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
