Ceki Gulcu wrote:<br>> Ralph Goers wrote:<br>>><br>>> I don't take offense at technical discussions on mailing lists. A lot can get misinterpreted.<br>Good to hear.<br>>> Instead, I suggest you take a look at the code and see if you think it is a horrible idea. <br>
I will, but not right now. I'm pretty sure it's not a horrible idea, though ;)<br>>> 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.<br>
><br>> 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?<br>><br>>> 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.<br>
><br>> Precisely. If push comes to shove, referring to my previous example using object of type "Article", we could write<br>><br>> MDC.put("article", article); // push data<br>> <a href="http://logger.info">logger.info</a>("article modified");<br>
> MDC.remove("article"); // mandatory clean up<br>><br>> However, this is less convenient than writing,<br>><br>> <a href="http://logger.info">logger.info</a>("article modified", article);<br>
><br>> Note the lack of an anchor in the message. This is to emphasize that<br>> we are using the argumentArray as an extension point, circumventing<br>> usual message formatting. It is the responsibility of<br>
> "article"-specific appenders to process articles. This is similar to<br>> the way MDC data is not always necessarily printed. In the previous<br>> example, we are using the MDC as an extension point, albeit a clumsy<br>
> one.<br>><br>Using Ralphs example:<br>logger.logEvent(EventData data)<br><br>Wouldn't it be possible to hide all that init and cleanup in the logEvent method?<br>e.g. something like the following<br>void logEvent(EventData data) {<br>
EventDataHolder.set(data);<br> info("whatever");<br> EventDataHolder.reset();<br>}<br><br>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?<br>
<br>>> Ralph<br>Joern.<br><br>(gmail is completely snafud at the moment...)<br>