polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Logging SPI?
Date Thu, 30 Nov 2017 00:19:14 GMT
As usual, good feedback...

On Thu, Nov 30, 2017 at 5:09 AM, Kent SĂžlvsten <kent.soelvsten@gmail.com>

> On Sat, Nov 25, 2017 at 4:41 AM, Niclas Hedhman <niclas@hedhman.org>
> wrote:
> > 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.

The reason I wanted @Structure is to capture the caller's module, rather
than the service's. And that the implementation ends up being a @Service,
just like UnitOfWork ends up delegating to services.

But, when thinking about it, UnitOfWorkFactory is now optionally a Service.
So, I should check how the @Structure semantics are handle or if there is a
design flaw, and if it is done correctly, perhaps use the same mechanism.

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

Well, one use-case I have in mind is that code should be able to enable
TRACE for one or more methods programmatically, to do measurements in
production selectively. Maybe a Concern does a TRACE every 1000 requests or
so and capture that data in a timeseries.

Once there is an interface for that, then other use-cases are likely to
surface soon enough, maybe time sensitive debug capture.

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

Maybe (Side-Effect, though). Let's see if usecases shows up that can't
easily be done with fragments.

> >     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);

Yeah, unless the entry is expensive to create instead...

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

Yeah, you might be on to something here. Is it time to do ApplicationEvent
design first? 4 visible event buses, one in the module, one in the layer
and one for each above/below layer? That sounds quite innovative, and only
possible with our structure enforcement. Possibly introduce custom-made
"global" eventbuses as well. Each of these ties into a implementations
similar to EntityStores. Should kick up a new thread on this...

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

Well, I would guess that a political committee would not come up with
something awesome, but instead enforce something bad and utterly
complicated onto some poor industries. But hey, I could be proven wrong.

I think for us, this is a matter of an @Audit annotation with a bunch of
fields, such as "name", "reference", "description" and the whole
invocation, with method and arguments (possibly filtered out with another
annotation), to be passed to a service, with implementations taking care of
store and forwards.

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

Well, preferably I want to disable the use of SLF4J and similar APIs in
Polygene application code. Not sure that we can/should manage that. The
usecase I had in mind was that external libraries are not going to change
to Polygene, and it is those I want to capture. Some better libraries, such
as Restlet, has a pluggable implementation, but most are hardcoded to one
or the other.

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

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