September 2014 - logback-dev

[JIRA] (LOGBACK-986) build fails on our build server due to missing directory
by Hideki Yamamura (JIRA) 20 Sep '14

20 Sep '14

1 0

[JIRA] (LOGBACK-1014) ReconfigureOnChangeFilter doesn't work with scan=true in Tomcat/war deployment
by Lukasz Kryger (JIRA) 20 Sep '14

20 Sep '14

1 0

I'd like to add you to my professional network on LinkedIn
by Kanapathipillai Senthuran 17 Sep '14

17 Sep '14

Hi, I'd like to add you to my professional network on LinkedIn. - Kanapathipillai Accept: http://www.linkedin.com/blink?simpleRedirect=0ScPATdzsNczsVczgUczATcjARfkh9… You received an invitation to connect. LinkedIn will use your email address to make suggestions to our members in features like People You May Know. Unsubscribe here: http://www.linkedin.com/blink?simpleRedirect=1EoQkO9ndLsj0Q9npBp2RHoS5ypSZI… Learn why we included this at the following link: http://www.linkedin.com/blink?simpleRedirect=3wUdPgZp4BBr6dFt79x9DhPpnlDnSl… © 2014, LinkedIn Corporation. 2029 Stierlin Ct. Mountain View, CA 94043, USA

1 0

vote for extending the AbstractSocketAppender
by Sebastian Gröbler 16 Sep '14

16 Sep '14

Hey Logback-Devs, I recently developed an “FileBufferingSocketAppender” for the logback-android (see https://github.com/tony19/logback-android/pull/57) project in order to have a more robust SocketAppender implementation. 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. 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. 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. The only difference is the way the events are being buffered (in-memory vs. on-disk), which I think could be configurable. So I am asking the logback developers for their opinion: 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. Thanks for your time. Sebastian Btw. The mailman app gives a lot of errors during registration to the dev mailing list.

2 1

[JIRA] (LOGBACK-747) maxHistory doesnot normally work in SizeAndTimeBasedFNATP
by Fabrizio Giudici (JIRA) 10 Sep '14

10 Sep '14

1 0

In memory logging
by Somaiya, Deepak 09 Sep '14

09 Sep '14

We have a requirement to keep logEvents(logs) in memory for certain configurable time even if logging is turned off i.e in that case logback logger should just keep the logging data in memory and should not write it to logfile. Any help will be appreciated. Deepak

1 0

[JIRA] (LOGBACK-1013) %contentResponse is always empty.
by Fyren (JIRA) 08 Sep '14

08 Sep '14

1 0

[JIRA] (LOGBACK-309) Getting Java java.lang.ClassNotFound except with v1.0.0 & Jetty 7
by Fyren (JIRA) 08 Sep '14

08 Sep '14

1 0

[JIRA] (LOGBACK-1009) java.lang.NoClassDefFoundError when using embedded Jetty
by Fyren (JIRA) 08 Sep '14

08 Sep '14

1 0

[JIRA] (CONSPLUG-44) Logback-Beagle doesn't work in Eclipse 4.3 Kepler
by Stefano Cardinale (JIRA) 07 Sep '14

07 Sep '14

1 0