polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Logging SPI?
Date Sat, 25 Nov 2017 03:41:35 GMT

We have relatively little logging going on in the Core Runtime and also in
most libraries/extensions. Part of the reason is that there is not enough
consensus on what the best logging approach is, and the most used ones are
all horrible.

I suggest that we introduce a Logging Extension SPI, and in good Polygene
tradition define our direct needs from top/down, and then allow for
pluggable extensions to deal with this as they see fit.

I think there is no need for a "LoggerFactory" (I could be wrong), but that
we simply introduce a few types to be injectable in @Structure scope, each
dedicated for the purpose, instead of the generic "log" that is prevalent
in logging systems deriving from Log4j. There are also control needs, as I
prefer to not have external configuration as the primary controller for
what is used or not, since that will effectively become implementation
specific. Things like log namespace and enable/disable must exist in the
SPI, possibly other things. And I think the extension of controls should
also be a prescribed mechanism, maybe have additional common configuration
options in the SPI, even if they don't apply to all implementations, e.g.
Formatting which is very common, but not for a log that writes entities.

I see 4 distinct subsystems within this SPI;

    Trace -  dealing with tracing of methods. Since we own the method
invocations, this will be relatively easy to do throughout a Polygene
application, and this injectable type is about controlling what is traced,
where reporting goes and what type of timing should be applied. Here is the
greatest level of integration into the Core Runtime.
In the library-logging, this is enabled in bootstrap, but I have since
changed my mind and think we need it to be controllable in runtime.

    Debug - We all need debug information, and be able to let the code tell
us what is going on. The output is dedicated for developers, and is
disabled in Application.production mode. This is one of the most common
use-cases, especially for us developers. *@Structure Debug debug;* and
reasonable methods on that type is all we need. We should also try to use
lambdas here, to get around the *if( debug.isEnabled() ){}*, which is ugly
and *debug.debug( () -> "here!" + param );* would look better and don't
incur the cost of message construction if not enabled.

    LogBook - Better name might needed. The "Captain's Log" is all about
the information that production operations personnel is interested in.
Important state changes, events and other relevant information is to be
communicated here.

    Audit  -  Many business applications have Audit requirements. I think
we should have dedicated support for this, rather than expecting people to
model the whole infrastructure from scratch.

As usual, I think Polygene should provide all these things in much more
type-safe fashion and customizable types, than what we have in "traditional
logging" systems.

By making this an SPI, and by having Noop implementation(s) as default, it
is much easier for people to default to using this, rather than SLF4J,
which frankly is horrible (albeit prolific in the enterprise).

In the implementation side, there will be room for both traditional
solutions as well as innovation. Oh, yeah... We should try to figure out if
we can redirect the existing slf4j, log4j, jdk, commons-logging and what
not APIs to go through our SPI, to provide a unified channel for Polygene


Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

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