- logback-user - mailman3.qos.ch

Versioning policy?
by list+ch.qos.logback＠io7m.com 25 Feb '17

25 Feb '17

Hello. I use Logback and SLF4J in a rather large number of projects. I like to keep dependencies up-to-date, and this means that I end up incrementing a large set of version numbers fairly frequently. It would reduce my workload if I could specify a version range in my dependency declarations for both Logback and SLF4J. However, I can only do this safely if I know the versioning policy of both of those projects. It sort of looks like they use something like Semantic Versioning [0], but I don't see an explicit policy written down anywhere. Can I use version ranges such as [1.7.0, 2.0.0) safely? M [0] http://semver.org/

2 2

Logback p2 repository unreachable
by contact＠goko.fr 09 Feb '17

09 Feb '17

Hello, I’ve been using the logback p2 repository for some eclipse build using P2 (https://logback.qos.ch/p2/) For a few weeks ( probably January 2017, but not sure), it’s unreachable with the following error : Internal error: java.lang.RuntimeException: Failed to load p2 repository with ID 'logback' from location http://logback.qos.ch/p2/: Unable to read repository at http://logback.qos.ch/p2/content.xml. sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target -> [Help 1] org.apache.maven.InternalErrorException: Internal error: java.lang.RuntimeException: Failed to load p2 repository with ID 'logback' from location http://logback.qos.ch/p2/ Trying to access it in the browser gives a 403 error. Could you please fix this ? Thanks

2 2

Release of logback version 1.2.0
by Ceki Gülcü 08 Feb '17

08 Feb '17

Hello all, I am happy to announce the release of logback version 1.2.0. It contains bug fixes and significant *performance* improvements. It should hit the Maven central repository by the time you read this message. This release also fixes a rather severe serialization vulnerability in SocketServer and ServerSocketReceiver. Users running these components should upgrade immediately. Please refer to the news page for precise details. http://logback.qos.ch/news.html For review of performance figures, see: http://tinyurl.com/logbackPerf You can receive logback related announcements by subscribing to the QOS.ch announce mailing list. To subscribe to QOS.ch announce list, please visit the following URL. http://www.qos.ch/mailman/listinfo/announce You may also receive announcements via twitter by following: https://twitter.com/qos_ch Enjoy, -- Ceki

1 0

Benchmark
by Jiri Pejchal 07 Feb '17

07 Feb '17

Hi, I've tried to run logback-perf, may you'll find the result useful. Jiří Pejchal logback 1.1.10, CPU E3-1240 v5 @ 3.50GHz, Samsung SSD 850 PRO 128GB, JDK 1.8.0_102 "Benchmark","Mode","Threads","Samples","Score","Score Error (99.9%)","Unit" "ch.qos.logback.perf.FileAppenderBenchmark.log4j1File","thrpt",1,10,1577.009429,33.154970,"ops/ms" "ch.qos.logback.perf.FileAppenderBenchmark.log4j2File","thrpt",1,10,1997.150618,5.731020,"ops/ms" "ch.qos.logback.perf.FileAppenderBenchmark.log4j2RAF","thrpt",1,10,2141.647559,8.157930,"ops/ms" "ch.qos.logback.perf.FileAppenderBenchmark.logbackFile","thrpt",1,10,2480.481451,71.973275,"ops/ms" "Benchmark","Mode","Threads","Samples","Score","Score Error (99.9%)","Unit" "ch.qos.logback.perf.FileAppenderBenchmark.log4j1File","thrpt",2,10,1124.216809,24.067386,"ops/ms" "ch.qos.logback.perf.FileAppenderBenchmark.log4j2File","thrpt",2,10,2759.163123,37.934327,"ops/ms" "ch.qos.logback.perf.FileAppenderBenchmark.log4j2RAF","thrpt",2,10,2739.519271,39.348186,"ops/ms" "ch.qos.logback.perf.FileAppenderBenchmark.logbackFile","thrpt",2,10,1448.307609,14.708407,"ops/ms" "Benchmark","Mode","Threads","Samples","Score","Score Error (99.9%)","Unit" "ch.qos.logback.perf.FileAppenderBenchmark.log4j1File","thrpt",4,10,778.720898,35.585861,"ops/ms" "ch.qos.logback.perf.FileAppenderBenchmark.log4j2File","thrpt",4,10,2410.408163,74.131141,"ops/ms" "ch.qos.logback.perf.FileAppenderBenchmark.log4j2RAF","thrpt",4,10,2833.438968,192.704404,"ops/ms" "ch.qos.logback.perf.FileAppenderBenchmark.logbackFile","thrpt",4,10,664.899426,174.136282,"ops/ms" "Benchmark","Mode","Threads","Samples","Score","Score Error (99.9%)","Unit" "ch.qos.logback.perf.FileAppenderBenchmark.log4j1File","thrpt",8,10,444.521720,4.222798,"ops/ms" "ch.qos.logback.perf.FileAppenderBenchmark.log4j2File","thrpt",8,10,1877.270743,563.989875,"ops/ms" "ch.qos.logback.perf.FileAppenderBenchmark.log4j2RAF","thrpt",8,10,1718.415344,355.749375,"ops/ms" "ch.qos.logback.perf.FileAppenderBenchmark.logbackFile","thrpt",8,10,589.209144,14.991014,"ops/ms" "Benchmark","Mode","Threads","Samples","Score","Score Error (99.9%)","Unit" "ch.qos.logback.perf.FileAppenderBenchmark.log4j1File","thrpt",16,10,1047.869080,31.680525,"ops/ms" "ch.qos.logback.perf.FileAppenderBenchmark.log4j2File","thrpt",16,10,958.811252,9.776799,"ops/ms" "ch.qos.logback.perf.FileAppenderBenchmark.log4j2RAF","thrpt",16,10,923.054985,12.930723,"ops/ms" "ch.qos.logback.perf.FileAppenderBenchmark.logbackFile","thrpt",16,10,627.107129,26.521755,"ops/ms" "Benchmark","Mode","Threads","Samples","Score","Score Error (99.9%)","Unit" "ch.qos.logback.perf.FileAppenderBenchmark.log4j1File","thrpt",32,10,782.954165,44.671984,"ops/ms" "ch.qos.logback.perf.FileAppenderBenchmark.log4j2File","thrpt",32,10,947.090112,14.686491,"ops/ms" "ch.qos.logback.perf.FileAppenderBenchmark.log4j2RAF","thrpt",32,10,887.397303,9.720897,"ops/ms" "ch.qos.logback.perf.FileAppenderBenchmark.logbackFile","thrpt",32,10,605.394268,47.669206,"ops/ms" "Benchmark","Mode","Threads","Samples","Score","Score Error (99.9%)","Unit" "ch.qos.logback.perf.FileAppenderBenchmark.log4j1File","thrpt",64,10,1059.913755,35.506168,"ops/ms" "ch.qos.logback.perf.FileAppenderBenchmark.log4j2File","thrpt",64,10,972.569039,42.377445,"ops/ms" "ch.qos.logback.perf.FileAppenderBenchmark.log4j2RAF","thrpt",64,10,990.437705,18.712172,"ops/ms" "ch.qos.logback.perf.FileAppenderBenchmark.logbackFile","thrpt",64,10,539.095359,52.330557,"ops/ms"

2 6

Release of logback version 1.1.10
by Ceki Gülcü 05 Feb '17

05 Feb '17

Hello all, I am happy to announce the release of logback version 1.1.10. It contains bug fixes and significant *performance* improvements. It should hit the Maven central repository by the time you read this message. Please refer to the news page for precise details. http://logback.qos.ch/news.html You can receive logback related announcements by subscribing to the QOS.ch announce mailing list. To subscribe to QOS.ch announce list, please visit the following URL. http://www.qos.ch/mailman/listinfo/announce You may also receive announcements via twitter by following: https://twitter.com/qos_ch Enjoy, -- Ceki

1 0

logback-access in an embedded jetty server
by Jan-Olav Eide 01 Feb '17

01 Feb '17

I have small main program that fires up a Jetty 9 server. This server is able to run/deploy any war file supplied to it as a command line argument. I construct a *logback-access* appender programmatically, give that appender to an instance of *ch.qos.logback.access.jetty.RequestLogImpl* and wrap that instance in a *org.eclipse.jetty.server.handler.RequestLogHandler* that is finally supplied to the jetty server: handlers.addHandler(webappHandler(contextPath(), warURL())); handlers.addHandler(requestLogHandler()); server.setHandler(handlers); Now, the web-application also uses logback, and has those artifacts in its *WEB_INF/lib* directory inside the war. It appears that the logback-access configuration in the main program and the logging performed by the webapp somewhat interfere with eachother. The symptom is that I see nothing in the request log, so I guess the logging configuration in the webapp "wins", and overrides the request log configuration in the main program. If I do not deploy a webapp, but instead just serve some static files, the request log works as expected, so I believe that my appender is constructed correctly. Is there any way the logging configuration from the webapp and the request log configuration from the server can co-exist ?

2 9

Log IP address.
by Murray, Thomas - 3 24 Jan '17

24 Jan '17

I am using logback v1.1.3 with my deployed Weblogic application. I am trying to log client ip address along with the xForwaredFor IP address. I added the MDC filter to the application deployment web.xml file and modified the logback.xml file. The log output correctly displays the xForwardedFor IP address. However, I am getting a PARSER_ERROR for the client ip (IP=%h). Any ideas on logging the request source IP? Thanks Here is my configuration: <?xml version="1.0" encoding="UTF-8"?> <configuration> <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender"> <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"> <pattern>%d %-5p [IP=%h %X{req.remoteHost} %X{req.requestURI} External IP=%X{req.xForwardedFor}] - %msg%n</pattern> </encoder> </appender> <appender name="LOGFILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>applogs/${weblogic.Name}.log</File>  <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"> <pattern>%d %-5p [IP=%h %X{req.remoteHost} %X{req.requestURI} External IP=%X{req.xForwardedFor}] - %msg%n</pattern> </encoder> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>applogs/${weblogic.Name}-%d{yyyy-MM-dd}.log.%i.gz</FileNamePattern> <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"> <maxFileSize>25MB</maxFileSize> </timeBasedFileNamingAndTriggeringPolicy>  <maxHistory>3</maxHistory> </rollingPolicy> </appender> <root level="DEBUG"> <appender-ref ref="CONSOLE"/> <appender-ref ref="LOGFILE"/> </root> </configuration> ---------------------------------------------------------------------- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.

2 1

Status of LOGBACK-1189? (AccessEvent clears attributes on jetty recycled requests)
by Mark Elliot 23 Jan '17

23 Jan '17

I'm trying to get a solution to https://jira.qos.ch/browse/LOGBACK-1189, in which async logging for logback-access with Jetty incorrectly clears the attribute map due to bad logic in copyAttributeMap. I've proposed https://github.com/qos-ch/logback/pull/336 as a resolution to the problem. Would greatly appreciate some feedback on if this proposed change will be accepted, and if so, when it might be released, and if not, when we might expect a fix for LOGBACK-1189, which is affecting a number of projects, including Dropwizard: http://mailman.qos.ch/pipermail/logback-user/2016-September/004800.html Thanks.

1 0

AsyncAppender dropping events when thread is interrupted
by Jakob Bergendahl 23 Jan '17

23 Jan '17

Hi, As mentioned in a comment on LOGBACK-910, the AsyncAppender will silently drop events when the current thread is interrupted. The simplest test for this is: Thread.currentThread().interrupt(); log.warn("message 1"); // This was always dropped log.warn("message 2"); // This is also dropped since LOGBACK-910 was fixed I have recently spent a long time troubleshooting a case where an error was sometimes not logged because of this. Have you considered using something similar to Guava's Uninterruptibles.putUninterruptibly instead, i.e. try to put in a loop while interrupted and reset the interrupt status once the put succeeds? Code-wise this would mean changing AsyncAppenderBase from: private void put(E eventObject) { if (neverBlock) { blockingQueue.offer(eventObject); } else { try { blockingQueue.put(eventObject); } catch (InterruptedException e) { // Interruption of current thread when in doAppend method should not be consumed // by AsyncAppender } } to something like (assuming no Guava dependency): private void put(E eventObject) { if (neverBlock) { blockingQueue.offer(eventObject); } else { putUninterruptibly(eventObject); } } private void putUninterruptibly(E eventObject) { boolean interrupted = false; try { while (true) { try { blockingQueue.put(eventObject); break; } catch (InterruptedException e) { interrupted = true; } } } finally { if (interrupted) { Thread.currentThread().interrupt(); } } } Does this make sense? I would be willing to help out with this, but not sure what my next step should be. /Jakob

2 1

Re: [logback-user] Hi
by Navin Math 13 Jan '17

13 Jan '17

Hi Guys This is my conf file for logging in the app. In my java application, I want to display the exceptions in the file. What are the changes required in the following configuration to display all the e.printStackTrace() from the exception block whenever I get exception in my Java program instead of displaying it on the console. <configuration> <conversionRule conversionWord="coloredLevel" converterClass="play.api.Logger$ColoredLevel" /> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>%coloredLevel - %logger - %message%n%xException</pattern> </encoder> </appender> <appender name="FILE" class="ch.qos.logback.core.FileAppender"> <file>${application.home}/logs/play.log</file> <encoder> <pattern>%date [%level] from %logger in %thread - %message%n%xException</pattern> </encoder> </appender> <logger name="play" level="INFO" /> <logger name="application" level="DEBUG" /> <logger name="com.avaje.ebean.config.PropertyMapLoader" level="OFF" /> <logger name="com.avaje.ebeaninternal.server.core.XmlConfigLoader" level="OFF" /> <logger name="com.avaje.ebeaninternal.server.lib.BackgroundThread" level="OFF" /> <logger name="com.gargoylesoftware.htmlunit.javascript" level="OFF" /> <root level="ERROR"> <appender-ref ref="STDOUT" /> </root> <root level="ERROR"> <appender-ref ref="FILE" /> </root> <logger name="INFO" level="INFO"> <appender-ref ref="FILE" /> </logger> </configuration> Thanks Math On Fri, Jan 13, 2017 at 6:48 PM, Navin Math <hinavinmath(a)gmail.com> wrote: > Can I ask my questions here? >

1 0