polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kent SĂžlvsten <kent.soelvs...@gmail.com>
Subject Re: Logging SPI?
Date Wed, 29 Nov 2017 21:09:53 GMT
Hi Niclas.

As always a lot of interesting thoughts. A few thoughts/comments below.

On Sat, Nov 25, 2017 at 4:41 AM, Niclas Hedhman <niclas@hedhman.org> wrote:

> Everyone,
> 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.

Very much agree that we should avoid another Factory. But I actually would
prefer the types to @Service instead of @Structure - more like eg.
I find it more flexible to just use a ServiceFinder internally for finding
the implementation. We could consider using a ServiceReference internally
to allow for them being optional.

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.

Some sort of Service activation/passivation?

> 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.

An extra concern added automatically to everything?

>     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.

Note that logger#isDebugEnabled may not be necessary at all, since eg.
SLF4J has support for something like

Object entry = new SomeObject();
logger.debug("The entry is {}.", entry);

>     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.

A special case of a more generic ApplicationEvent concept?

>     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.

This is quite a hot topic in the EU area a.t.m. (GDPR). A good solution
here would really be awesome!

> 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
> applications.

Not sure we should do this channelling except for the debug logging
- I tend to think it is much better to let users migrate their code to use
a more explicit API
- and thus expose the @Service / @Structure to application code.

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


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