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.
