http://bugzilla.qos.ch/show_bug.cgi?id=100 ------- Comment #19 from noreply.ceki@qos.ch 2008-03-22 19:32 ------- While it is true that logging behavior would depend on the underlying logging system, the changes we are talking about are in the logback API and only in the logback API. So if the user wishes to track a message processed over several applications distributed over many machines. It would be interesting for her to specify parameters such as e.g. server id, application name, request id, transaction id, user id etc. The last three parameters are specific to the request being processed and presumably should be specified in the logging event as parameters. It could look as follows: LogbackEventMap lem = new LogbackEventMap(); lem.put("transactionId", getTransactionId()); lem.put("serverId", getServerId()); lem.put("requestId", getRequestId()); lem.put("userId", getUserId()); org.slf4j.Logger logger = LoggerFactory.getLogger("..."); logger.debug("Started processing message", lem); The first 5 lines are logback specific while the last 2 lines are just the SLF4J API. We are taking advantage of a detail in logback's implementation of the SLF4J API (which is by the way the subject of this bug). Thus, logback's implementation of SLF4J logger will carry on the argumentArray as is. Under certain strict restrictions, the argument array may even survive serialization unmodified. Assuming the use case I describe here is not that interesting, then I think your line of thought is very valid. It brings interesting simplifications. However, I am inclined to think that the use case is an important one, and worth tying application code to logback's implementation. Again, no one is forced to take advantage of enhancements in logback's implementation of SLF4J's Logger interface. Moreover, the Logger interface was not modified in any way. In any case, many thanks for bearing with me on this issue. I definitely appreciate it. Given that bugs corrected in the trunk are being reported as duplicates of previous bug reports, I wish to cut a new release some time next week. -- Configure bugmail: http://bugzilla.qos.ch/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.