
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hey Logback-Devs,<div><br></div><div>I recently developed an “FileBufferingSocketAppender” for the logback-android (see <a href="https://github.com/tony19/logback-android/pull/57">https://github.com/tony19/logback-android/pull/57</a>) project in order to have a more robust SocketAppender implementation.</div><div>The appender basically buffers events to disk so in case of a crash or connection problem no events are being lost. This is especially an important feature for crash-reporting on android devices.</div><div>After some discussions with Tony we decided that it might make sense to put this Appender in either the logback, logback-contrib or logback-extension project and refer to it from the logback-android project, because the feature it self is not really specific to android.</div><div><br></div><div>The FileBufferingSocketAppender was initially developed before the AbstractSocketAppender got the internal queue to buffer events in memory. After some thinking I found that my FileBufferingSocketAppender is basically not much different to the most recent implementation of the AbstractSocketAppender.</div><div>The only difference is the way the events are being buffered (in-memory vs. on-disk), which I think could be configurable.</div><div><br></div><div>So I am asking the logback developers for their opinion:</div><div><br></div><div>Does it makes sense to make the queue implementation of the AbstractSocketAppender configurable? The default would stay the same, but the user would also be able to either provide his own implementation or choose between in-memory and on-disk.</div><div><br></div><div><br></div><div>Thanks for your time.</div><div>Sebastian</div><div><br></div><div><br></div><div>Btw. The mailman app gives a lot of errors during registration to the dev mailing list.</div></body></html>