January 2017 - logback-user

Logback => TLS/SSL => Syslog ?
by Otis Gospodnetić 21 Feb '19

21 Feb '19

Hi, Does Logback support sending logs to Syslog servers via TLS/SSL? I have a feeling Logback doesn't have a SyslogAppender that can send data using TLS. I say that because I don't see a mention of "syslog" on http://logback.qos.ch/manual/usingSSL.html and I see http://jira.qos.ch/browse/LOGBACK-890 that mentions TLSSyslogAppender, but it looks like this never ended up in Logback. I've only found it committed here: https://github.com/balabit/logback/commit/e0d89de2536e0925a6c816a50793f6a74… Could anyone please clarify? Thanks, Otis -- Monitoring * Alerting * Anomaly Detection * Centralized Log Management Solr & Elasticsearch Support * http://sematext.com/

2 1

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