polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Discuss; SLF4J in Core
Date Tue, 31 Mar 2015 13:21:44 GMT
On Tue, Mar 31, 2015 at 12:33 PM, Kent SĂžlvsten <kent.soelvsten@gmail.com>

> I just read the old website documentation for the (deprecated??) logging
> library - discussing uses ogf "logging" like  tracing, debugging,
> logging:   http://qi4j.org/2.0/library-logging.html
> Tracing is pretty simple in qi4j.
> "Logging" refers to something like application events.
> Debugging is .... well the small weird messages we always wished we put
> into our code, but didn't, so we put it into the code for the next
> release, look at it after the release and then never look at that
> logging again.
> Maybe there is simply not much left?

The Logging Library needs a re-think in a big time.

Some sort of event mechanism has already been mentioned in this discussion.

Yes, true that logging can be seen as events instead of "typed
notifications over interfaces". Will try to think around the differences...

> Implementations could then choose to log (to file system, some database
> audit log or send to a JMS Queue, whatever).

I think I already mentioned, that such notification (if very efficient) is
actually much more than "logging". So, in Qi4j terms, it is actually a kind
of "in-method" (unlike "post-method") SideEffect (SideEffects are aspects
that can't modify the argmuments nor return values in a method call).

In the Logging library, it is done like;

public class ...
    @Optional @This Debug debug;

        if( debug != null )
            debug.debug( Debug.NORMAL, "Something happened." );

But this is very much in the old vein of logging. If "Debug" type above is
a type provided by the user, and it is easy to set up (i.e. no setup), then
we might be on to something.

Hmmm.... Interesting.... I would like to call this "Activity Interfaces"...
More on that later.

We could choose to provide a default implementation debug logging
> everything using java.util.logging, thus avoiding external dependencies.
> Of course there would be challenges to avoid excessive work "when noone
> listens" - but application events have been discussed years ago (i think
> without being solved) - maybe it is about time to look at that again?

Excessive work limitation is important. That is why I prefer a typed
interface and each argument is passed as-is. And the "isXyzEnabled()" (I
think) should be handled with a "== null" as above.

I think no one objects to strip slf4j for now, and I will go ahead with
that while this plays out.


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