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