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...)