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 <[email protected]> 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. EntityStores. 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. > > > WDYAT? > > > Cheers > -- > Niclas Hedhman, Software Developer > http://polygene.apache.org - New Energy for Java > /Kent
