You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Patrick Rhomberg (JIRA)" <ji...@apache.org> on 2018/03/20 20:58:00 UTC

[jira] [Created] (GEODE-4902) Log markers filter some messages pathologically

Patrick Rhomberg created GEODE-4902:
---------------------------------------

             Summary: Log markers filter some messages pathologically
                 Key: GEODE-4902
                 URL: https://issues.apache.org/jira/browse/GEODE-4902
             Project: Geode
          Issue Type: Bug
            Reporter: Patrick Rhomberg


Many logging calls across all log levels are marked with {{o.a.g.internal.logging.log4j.LogMarker}} markers for selective enabling and debugging.  All these markers have a parent marker {{GEODE_VERBOSE}}.  However, per the default given in {{geode-core/src/main/resources/log4j2.xml}}, this parent marker is set to filter log messages.

Many of these log messages are invoked at the {{info}} level, suggesting an expectation that the message would be seen.

These markers should be refactored to (a) include by default markers that commonly or exclusively appear in coarse-grained logging levels, and (b) to reorganize the markers' parent/child relationships so that they are not blanket-disabled by default.  Only those markers attacked to more verbose logging should be disabled by default.

---

Additionally, the log classes {{FastLogger}} and {{LogWriterLogger}} are themselves slightly pathological.  Notably, the former overrides some {{isEnabled}} aliases but leaves exposed default many of the root method signatures.  The latter pathologically includes a reference to itself as a field unto itself in the lines:
{noformat}
private final ExtendedLoggerWrapper logWrapper;
// ...

  private LogWriterLogger(final Logger logger, final String connectionName,
      final boolean isSecure) {
    super((AbstractLogger) logger, logger.getName(), logger.getMessageFactory());
    this.logWrapper = this;
    // ...
  }
{noformat}

These classes could use refactoring in their own right, perhaps as a separate child ticket.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)