[logback-dev] RFC: LoggingEvent redesign

[Jörn Huxhorn]

Ceki Gulcu wrote:
> Ralph Goers wrote:
>>
>> I don't take offense at technical discussions on mailing lists. A lot can
get misinterpreted.
Good to hear.
>> Instead, I suggest you take a look at the code and see if you think it is
a horrible idea.
I will, but not right now. I'm pretty sure it's not a horrible idea, though
;)
>> What I'm currently actually using, but would replace with this, does have
more knowledge of Logback, specifically so it can pass the objects to the
Appender. Unfortunately (at least I think so), SLF4J's LocationAwareLogger
doesn't provide a method to pass that information along.
>
> I was meaning to ask. Why do you need support from LocationAwareLogger for
argument arrays if you are going to use logback-classic underneath SLF4J?
>
>> I assume an NDC is based on a ThreadLocal? This works well for data that
lasts the lifetime of the request in progress. It is dangerous to use for
data for a specific event as that data must be cleared after the event is
completed - without disturbing other data that might have been stored in it.
>
> Precisely. If push comes to shove, referring to my previous example using
object of type "Article", we could write
>
> MDC.put("article", article); // push data
> logger.info("article modified");
> MDC.remove("article");  // mandatory clean up
>
> However, this is less convenient than writing,
>
> logger.info("article modified", article);
>
> Note the lack of an anchor in the message. This is to emphasize that
> we are using the argumentArray as an extension point, circumventing
> usual message formatting. It is the responsibility of
> "article"-specific appenders to process articles.  This is similar to
> the way MDC data is not always necessarily printed. In the previous
> example, we are using the MDC as an extension point, albeit a clumsy
> one.
>
Using Ralphs example:
logger.logEvent(EventData data)

Wouldn't it be possible to hide all that init and cleanup in the logEvent
method?
e.g. something like the following
void logEvent(EventData data) {
   EventDataHolder.set(data);
   info("whatever");
   EventDataHolder.reset();
}

That way, a special appender could access the EventData from the ThreadLocal
storage... assuming that it is executed synchronously... but I guess that
guaranteed delivery mandates synchronous handling anyway, right?

>> Ralph
Joern.

(gmail is completely snafud at the moment...)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/logback-dev/attachments/20090225/25a82097/attachment.htm>