Logging configuration shared with wonder-slim: ng-logging and ng-logging-logback #72

wonder-slim has grown logging infrastructure (undur/wonder-slim#44) that is almost entirely independent of WebObjects. Moving it into ng-objects would let ng applications use it, and let an application carry its logging configuration unchanged between WO and ng.

Open question first: the key names

wonder-slim's keys are er.logging.level.<logger>, er.logging.level.root and er.logging.pattern. They are unreleased, so they can still change. Either:

• ng reads er.logging.* as it is, making it the shared name, or
• a neutral name is picked now (say ng.logging.*), which wonder-slim reads instead, or as well.

What it is

• A backend interface, one implementation per logging library, found through ServiceLoader (META-INF/services/…); at most one may be on the classpath, two stop the launch.
• Configuration in layers, lowest first:
  1. Project Wonder style log4j.logger.* / log4j.rootLogger levels (for a backend other than log4j's)
  2. the neutral keys: a level per logger, and the console output's layout
  3. the backend's own configuration (logback.xml, logback.configurationFile), which wins where it names a logger
  4. levels set on the running instance, which win over everything
• Following changes: logging is configured again when a logging property changes.
• Capture of recent log lines in memory, for a dev/admin log view (overlaps NGConsoleCapture).
• A logback backend.

What ties it to wonder-slim today, and the seams

• Two key constants from ERXP → owned by the module.
• "Was this key set on the running instance?" asked of ERXConfigurationManager → a Predicate<String> the host supplies.
• ERXConfigurationManager.onChange() for following changes → a callback the host supplies. Until NGProperties can report changes (its FIXMEs ask for exactly this), an ng application configures once.
• The backends read System.getProperties() → configure( Properties ).

Suggested shape

• ng-logging: the interface, the layers, the ServiceLoader lookup, capture, the host hooks. Its own module rather than ng-core, to keep ng-core free of logging choices.
• ng-logging-logback: the backend.

WebObjects-specific pieces stay in wonder-slim: the NSLog bridge, the WOOutputPath console redirect, log4j-over-slf4j (WO itself calls the log4j API), and the reload4j backend with Wonder's log4j appenders and layouts. ng would be logback-only.

wonder-slim side: undur/wonder-slim#153