polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niclas Hedhman (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (POLYGENE-277) Logging Extension SPI
Date Sat, 28 Apr 2018 02:16:00 GMT

    [ https://issues.apache.org/jira/browse/POLYGENE-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16457301#comment-16457301

Niclas Hedhman commented on POLYGENE-277:

 * Separation of Debugging, Application Log and Application Audit
 * Enable trace per Composite at bootstrap (even runtime?)
 * Strongly typed Log Events
 * Custom Log Event types, defined by Application Code and not only extension implementation.
 * Allow Log Events to be entities, and allow the Entity Store used for those events to still
emit Log Events, which then needs to be directed to the secondary target.
 * Cleaning up of stacktraces, so that all Polygene magic is removed, and a configurable policy
for that. (i.e. collaboration with FragmentInvocationHandler and possibly making that better)

> Logging Extension SPI
> ---------------------
>                 Key: POLYGENE-277
>                 URL: https://issues.apache.org/jira/browse/POLYGENE-277
>             Project: Polygene
>          Issue Type: New Feature
>            Reporter: Niclas Hedhman
>            Priority: Major
> (sent to dev@polygene.apache.org on 25 Nov 2017)
> 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
>     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 applications.

This message was sent by Atlassian JIRA

View raw message