[
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:
-----------------------------------------
Features;
* 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 [email protected] 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 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 applications.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
