On Tue, Mar 31, 2015 at 12:33 PM, Kent Sølvsten <[email protected]> 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
