- logback-user - mailman3.qos.ch

ping about pull request / possible fix for http://jira.qos.ch/browse/LOGBACK-397
by David Byron 06 Dec '15

06 Dec '15

Curious if there's any more I can do to generate some activity on https://github.com/qos-ch/logback/pull/285. I run into this exception often enough that I'd love to see a fix (mine or another) merged and if I'm even luckier, released out in the world. Thanks for your help. -DB

1 0

Extending Logback Gaffer to allow SiftingAppender to be configured when using Groovy DSL
by yihtserns 05 Dec '15

05 Dec '15

Hi. So, I made a little project to extend Logback Gaffer so that SiftingAppender can be configured in Groovy DSL, like this: ``` import ch.qos.logback.classic.sift.SiftingAppender import ch.qos.logback.classic.sift.MDCBasedDiscriminator import ch.qos.logback.classic.PatternLayout appender("SIFT", SiftingAppender) { discriminator(MDCBasedDiscriminator) { key = "userid" defaultValue = "unknown" } sift { appender("FILE-${userid}", FileAppender) { file = "${userid}.log" append = false layout(PatternLayout) { pattern = "%d [%thread] %level %mdc %logger{35} - %msg%n" } } } } root(DEBUG, ["SIFT"]) ``` The codebase still needs a little bit of polish, but functionality wise, it should work OK. To try it out, go to https://github.com/yihtserns/logback-gaffer-sift. Hope you'll like it. :) -- View this message in context: http://logback.10977.n7.nabble.com/Extending-Logback-Gaffer-to-allow-Siftin… Sent from the Users mailing list archive at Nabble.com.

1 0

Extending Logback Spring extension to allow <appender/> tags in Spring XML
by yihtserns 02 Dec '15

02 Dec '15

Hi. (Not sure if this is the correct place to post this, but... oh well.) So, I was checking out Logback Spring extension[1], and reached the part about declaring appender as bean in Spring XML[2]. I then thought, "hmm, maybe I can do something about this!" so I made a project[3] to allow declaring <appender /> tags in Spring XML. So instead of this: ``` <beans ...> ... <bean id="consoleAppender" class="ch.qos.logback.core.ConsoleAppender" init-method="start" destroy-method="stop"> <property name="context" value="#{ T(org.slf4j.LoggerFactory).getILoggerFactory() }"/> <property name="encoder"> <bean class="ch.qos.logback.classic.encoder.PatternLayoutEncoder" init-method="start" destroy-method="stop"> <property name="context" value="#{ T(org.slf4j.LoggerFactory).getILoggerFactory() }"/> <property name="pattern" value="%date %-5level [%thread] %logger{36} %m%n"/> </bean> </property> </bean> ... </beans> ``` you can do this: ``` <beans ... xsi:schemaLocation="... http://logback.qos.ch logback-lenient.xsd"> ... <appender name="consoleAppender" class"ch.qos.logback.core.ConsoleAppender" xmlns="http://logback.qos.ch"> <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"> <pattern>%date %-5level [%thread] %logger{36} %m%n"</pattern> </encoder> </appender> ... </beans> ``` To try it out, go to https://github.com/yihtserns/logback-spring-config. Hope you'll like it. :) [1] https://github.com/qos-ch/logback-extensions/wiki/Spring [2] https://github.com/qos-ch/logback-extensions/wiki/Spring#using-applicationc… [3] https://github.com/yihtserns/logback-spring-config -- View this message in context: http://logback.10977.n7.nabble.com/Extending-Logback-Spring-extension-to-al… Sent from the Users mailing list archive at Nabble.com.

1 0

where is ${webapp.root}
by Miloslava Teneva 29 Nov '15

29 Nov '15

Hi All, we switched to logback from log4j.And everything was fine until we notice that parameter ${webapp.root} that we used with log4j, now is not recognize.We really need this because our logs are under our webapp dir.We use tomcat and we want our logs not to be in tomcat/bin directory.We even try logback-ext-spring.jar but without success.We really need your help and ideas.We don`t want to put relative paths.We want webapp.root to be taken dynamically. Thanks for your help. Have a nice day, Miloslava

3 2

Logback extensions missing debug info
by Aleksandr Dubinsky 27 Nov '15

27 Nov '15

Please include debugging info when compiling source code (in particular, Logback Spring extension), so that stepping through logback source code is possible when debugging.

3 2

Lilith 8.0.0 has been released!
by Jörn Huxhorn 15 Nov '15

15 Nov '15

This version of Lilith requires Java 8 update 66 or higher and will says so if you try to start it with an older version. You can still receive event from previous versions so if your application is still running Java 7 or lower just keep using the 0.9.44 artifacts. Keep in mind that Java SE 7 End of Public Updates has already been reached. It contains an important security fix related to deserialization and lots of small usability enhancements. See http://lilithapp.com/releases/8.0.0.xhtml for detailed release notes. Cheers, Jörn.

1 0

1.1.4 release date?
by Teng Wang 05 Nov '15

05 Nov '15

Hi, Are there any plans to release 1.1.4 soon? I don’t see any recent changes. We’d like to pull in the fix for LOGBACK-910 since it’s causing problems when used with Apache Samza. Thanks, Tony

1 0

Re: [logback-user] Truncation of log entry when using a specific sequence of '}]:' characters
by Jeffrey Olchovy 28 Oct '15

28 Oct '15

This was an issue with me not adhering to the (obsolete) syslog protocol (https://www.ietf.org/rfc/rfc3164.txt, section 4.1.3). Our TAG part of the message was greater than 32 characters and was being truncated. In the example, I used a false string ‘foo-service’. In reality, it was much longer (service-xxxxxxxxxxx). That, combined with the 12 character hex ‘pid’ and decorating brackets, pushed us over the limit. It rendered correctly with the spaces surrounding the hex characters since the whitespace violated the pattern that would attempt to identity (and subsequently, truncate) the TAG. There is no issue with logback’s layouts or the SyslogAppender. However, we would like to benefit from the outstanding issue and associated patch with regard to additional configuration of the SyslogAppender and SyslogStartConverter : http://jira.qos.ch/browse/LOGBACK-1011, https://github.com/qos-ch/logback/pull/139. These are quite old and I am curious if they are part of any planned releases. Thanks. We would like to On Oct 28, 2015, at 8:00 AM, logback-user-request(a)qos.ch wrote: > Date: Tue, 27 Oct 2015 12:45:05 -0400 > From: Jeffrey Olchovy <jeffo(a)tapad.com> > To: logback-user(a)qos.ch > Subject: [logback-user] Truncation of log entry when using a specific > sequence of '}]:' characters > Message-ID: <C5366591-1C27-40E0-AAC3-48C969030384(a)tapad.com> > Content-Type: text/plain; charset=windows-1252 > > Hello, I am experiencing an unexpected truncation of part of my log entry when using the SyslogAppender with the following suffixPattern: > <suffixPattern>foo-service[${HOSTNAME}]: %logger %msg</suffixPattern> > > The resulting output takes the form: > foo-service[f7e52cff05ba com.tapad.common.cache.SelfRefreshingCache Cache Constraints lookup refreshing… > foo-service[f7e52cff05ba com.tapad.common.cache.SelfRefreshingCache Cache Constraints lookup refreshed and now contains 284 items. > > Rather than the expected: > foo-service[f7e52cff05ba]: com.tapad.common.cache.SelfRefreshingCache Cache Constraints lookup refreshing… > foo-service[f7e52cff05ba]: com.tapad.common.cache.SelfRefreshingCache Cache Constraints lookup refreshed and now contains 284 items. > > If I add spaces between the intended variable ${HOSTNAME} and the square brackets, the log entries render as one would expect: > foo-service[ 28ed24577053 ]: com.tapad.common.cache.SelfRefreshingCache Cache Constraints lookup refreshing… > foo-service[ 28ed24577053 ]: com.tapad.common.cache.SelfRefreshingCache Cache Constraints lookup refreshed and now contains 284 items. > > Are there any known issues or workarounds that either will prevent or resolve this behavior? Or, alternatively, does this smell like something downstream of logback and more at the syslog level? > > Thank you.

1 0

PPG encrypted appender
by Rob GB 27 Oct '15

27 Oct '15

Hi LB people, I wonder what would be the way to create an encrypted file appender. Not sure if it is best to create a complete new appender or encoder. My strategy is to write encrypted lines, one by one, then logback rotates the file. Thanks.

1 0

Truncation of log entry when using a specific sequence of '}]:' characters
by Jeffrey Olchovy 27 Oct '15

27 Oct '15

Hello, I am experiencing an unexpected truncation of part of my log entry when using the SyslogAppender with the following suffixPattern: <suffixPattern>foo-service[${HOSTNAME}]: %logger %msg</suffixPattern> The resulting output takes the form: foo-service[f7e52cff05ba com.tapad.common.cache.SelfRefreshingCache Cache Constraints lookup refreshing… foo-service[f7e52cff05ba com.tapad.common.cache.SelfRefreshingCache Cache Constraints lookup refreshed and now contains 284 items. Rather than the expected: foo-service[f7e52cff05ba]: com.tapad.common.cache.SelfRefreshingCache Cache Constraints lookup refreshing… foo-service[f7e52cff05ba]: com.tapad.common.cache.SelfRefreshingCache Cache Constraints lookup refreshed and now contains 284 items. If I add spaces between the intended variable ${HOSTNAME} and the square brackets, the log entries render as one would expect: foo-service[ 28ed24577053 ]: com.tapad.common.cache.SelfRefreshingCache Cache Constraints lookup refreshing… foo-service[ 28ed24577053 ]: com.tapad.common.cache.SelfRefreshingCache Cache Constraints lookup refreshed and now contains 284 items. Are there any known issues or workarounds that either will prevent or resolve this behavior? Or, alternatively, does this smell like something downstream of logback and more at the syslog level? Thank you.

1 0