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

["Gardiner, Paul" <PGardiner@xxxxxxxxxxxxxx>]

Ironically, they turned it into a bundle as of 1.2.  To use it with 1.1, I would have to change it to include the slf4j api jar, and export the api.  With 1.3, since slf4j is a bundle, it exports the api, and I export only the binding package, which the slf4j bundle then reads.  

Re: MDC
Yes, I'm talking about context info via a thread local. It's a hashtable stored in an InheritableThreadLocal in log4j, and it's likely the same in logback, but I'm not sure.   I thought about putting it in the context object, but then I need to import the MDC classes, which means there would be a dependency on multiple logging systems.  The alternatives would be to mimic each technology that uses MDC, use reflection, or expose a new api, none of which are very appealing.   I'll post a message on the slf4j mailing list about ways to achieve this.  To tell the truth, I don't like MDC to begin with, since the information is often session oriented, and each post can be on a separate thread in a webapp, so you end up having to reset it all the time.  It would be nice to have an alternative that achieves the same end result.

Re: cache
Caching the decisions could get kind of tricky since dynamic cases are very common.  I have lots of customers that do time of day filtering for things like pager support.

re: marker filtering
Then I guess that's another reason to not cache the decisions.

-----Original Message-----
From: equinox-dev-bounces@xxxxxxxxxxx [mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Simon Kaegi
Sent: Friday, March 23, 2007 3:56 PM
To: Equinox development mailing list
Subject: [equinox-dev] Re: slf4j binding for log service


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

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev