| slf4j binding for log service [message #84871] |
Fri, 23 March 2007 13:09  |
Eclipse User |
|
|
|
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
|
|
|
| Re: slf4j binding for log service [message #84916 is a reply to message #84871] |
Fri, 23 March 2007 15:56  |
| Eclipse User |
|
|
|
Thats great! (moving to equinox-dev)
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@syntellect.com> wrote in message
news:eu11m9$tpc$1@utils.eclipse.org...
> 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
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.03313 seconds
Home