Hi guys. I did a quick'n'dirty conversion of Chainsaw to support LOGBack- instead of Log4J-Events. It works but I think I might have found a problem. It's also very well possible that I simply don't understand a LOGBack/SLF4J concept... While testing my changes I tried to send some Markers, too. The first problem I encountered was that the helper class org.slf4j.helpers.BasicMarker has a package-private constructor. I missed that MarkerFactory at that point and wrote my own SimpleMarker that did essentially the same as BasicMarker. This worked but Chainsaw would explode during event deserialization if my SimpleMarker class was not contained in the classpath. Is this expected behaviour or should LOGBacks SocketAppender always use BasicMarker instead of a user-implemented Marker class while serializing log events? I'm really not sure at all. After all, it *could* be worthwhile to use the applications original markers if there is some additional functionality beside tagging a log message... but isn't that in itself a misuse of the marker concept? Beside that, would it be possible to implement SLF4J's BasicMarker.toString somewhat like that: public String toString() { StringBuffer result = new StringBuffer(); result.append("BasicMarker[name=").append(name); if(markers.size()>0) { result.append(", {"); boolean first = true; for (Map.Entry<String, Marker> marker : markers.entrySet()) { if (first) { first = false; } else { result.append(", "); } result.append(marker.getValue()); } result.append("}"); } result.append("]"); return result.toString(); } So it would print contained markers instead of the current generic Object.toString()? This isn't really important but would be nice. Beside the mentioned problem I'm really very happy with LOGBack. I switched a major project a month ago and haven't had any problems beside the missing support in Chainsaw ;). I especially love the ability to change the logging configuration during runtime in a reasonable way. Thanks for all your work, Joern.