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>
wrote:

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


Niclas

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