[equinox-dev] Re: slf4j binding for log service

[Simon Kaegi <Simon_Kaegi@xxxxxxxxxx>]

(moved from newsgroup)

Thats great!
As luck would have we recently got the legal approval to use SLF4J albeit
1.1.
I'll try and spend some time early next week to setup the various
dependencies and other projects in the incubator and perhaps create a few
bugs to track this stuff.

re: MDC (I'm guessing you're talking about context passed in via thread
local)
Good question. The current ExtendedLogRecord adds a threadId and the
generic context object - perhaps we can add a bit more info, but for the
moment I think the logging would have to be pre-processed to stuff the MDC
into the context object at log time and vice-versa at reader time.

re: cache
Yep. The current implementation is just trying to show the concepts and we
need to think hard about caching and invalidation. On the back-end I want
to look at caching the isLoggable decisions however this implies that the
decision handed back by Filter is static.

re: marker filtering
Possibly. I know SLF4J went this way, however I think this would make
caching the decisions considerably harder. One approach might be to use the
isLoggable with context/marker only if the cached isLoggable decision holds
true.

-Simon

"Paul Gardiner" <pgardiner@xxxxxxxxxxxxxx> wrote in message
news:eu11m9$tpc$1@xxxxxxxxxxxxxxxxx...
> Simon, this is primarily to you.
>
> I created an slf4j binding to the log service in org.eclipse.equinox.log
in
> the incubator.  I also created a log reader for log4j.  Everything works
> great, but I have few issues.
>
> 1) I'm not sure how to get MDC data through.  SLF4J has no support for
it,
> but it wouldn't work even with a log4j or logback binding, because the
log
> reader is going to likely be reading on a different thread.  Any ideas?
>
> 2) The ExtendedLogServiceFactory.getLogger method returns a new instance
of
> LoggerImpl on every call.  This could result in a large number of
objects.
> To work around it, I am caching them in my slf4j logger in a WeakHashMap,

> but I think there should be something in your class to handle this.
>
> 3) The log filter method (LogFilter.isLoggable) takes a bundle, logger
name
> and log level.  This is fine if the reader is filtering on logger name,
but
> not if it's filtering on context, such as markers.  I think there should
be
> another Object parameter for context info.
> Regards,
>
> Paul
>
>