- logback-dev - mailman3.qos.ch

[JIRA] (LOGBACK-1507) Logback printing duplicates on the output console.
by QOS.CH (JIRA) 17 Feb '20

17 Feb '20

Karan Mehta created LOGBACK-1507: ------------------------------------ Summary: Logback printing duplicates on the output console. Key: LOGBACK-1507 URL: https://jira.qos.ch/browse/LOGBACK-1507 Project: logback Issue Type: Bug Components: logback-core Reporter: Karan Mehta Assignee: Logback dev list Attachments: image-2020-02-18-00-08-44-304.png, image-2020-02-18-00-09-48-950.png, logback.xml The logback.xml has been setup in consul and is fetched at compile time. Even though the logging levels and appenders are set correctly, each log appears twice. The dependency errors can be ignored (The dependencies are shaded) This is the startup log !image-2020-02-18-00-08-44-304.png! And this is the error I face: !image-2020-02-18-00-09-48-950.png! -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1506) Use %replace to operate on %exception in a configuration file, the exception is added to the end
by QOS.CH (JIRA) 15 Feb '20

15 Feb '20

YuSongyi created LOGBACK-1506: --------------------------------- Summary: Use %replace to operate on %exception in a configuration file, the exception is added to the end Key: LOGBACK-1506 URL: https://jira.qos.ch/browse/LOGBACK-1506 Project: logback Issue Type: Bug Components: logback-classic Affects Versions: 1.2.3 Environment: jdk 1.8 win10 Springboot Finchley.RELEASE Reporter: YuSongyi Assignee: Logback dev list Attachments: TIM截图20200215235542-2-1024x778.jpg, TIM截图20200215235542.jpg It will add the contents of the exception to the end of the formatted log. As shown below, according to the format defined above, its content should end at the arrow. logback.xml {code:java} <?xml version="1.0" encoding="UTF-8"?> <configuration> <include resource="org/springframework/boot/logging/logback/defaults.xml" /> <springProperty scope="context" name="springAppName" source="spring.application.name" /> <property name="LOG_FILE" value="${BUILD_FOLDER:-build}/${springAppName}" /> <appender name="kafkaAppender" class="com.github.danielwegener.logback.kafka.KafkaAppender"> <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"> <pattern> { "severity": "%level", "service": "${springAppName:-}", "trace": "%X{X-B3-TraceId:-}", "span": "%X{X-B3-SpanId:-}", "exportable": "%X{X-Span-Export:-}", "stack_trace": "%replace(%exception{10}){'\n',''}", "pid": "${PID:-}", "thread": "%thread", "class": "%logger{40}", "rest": "%message" } </pattern> </encoder> <topic>applog</topic> <keyingStrategy class="com.github.danielwegener.logback.kafka.keying.NoKeyKeyingStrategy" /> <deliveryStrategy class="com.github.danielwegener.logback.kafka.delivery.AsynchronousDeliveryStrategy" />  <producerConfig>bootstrap.servers=******** </producerConfig> </appender> <root level="INFO"> <appender-ref ref="kafkaAppender" /> </root> </configuration>{code} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1505) HTMLLayout - Performance Issue
by QOS.CH (JIRA) 14 Feb '20

14 Feb '20

Kapil Patil created LOGBACK-1505: ------------------------------------ Summary: HTMLLayout - Performance Issue Key: LOGBACK-1505 URL: https://jira.qos.ch/browse/LOGBACK-1505 Project: logback Issue Type: Improvement Components: logback-core Affects Versions: 1.3.0-alpha5, 1.1.8 Environment: Issue is not limited to any OS & hardware combination. Reporter: Kapil Patil Assignee: Logback dev list I observed this performance issue in 1.1.8 onward and even in latest 1.3.0-alpha5, same issue is present. ============================================= Problem statement: ============================================= We had configured SMTPAppender to generate error emails using HTMLLayout using default pattern. In production env, our process end up generating logger.error with 27MB of message which also had data (I know that at first place our system should not have generated 27MB of error message but that want happened and we observed this performance issue.) Here logback HTMLLayout was running for 70mins just to process that 27MB of data. I know you might think I am stupid, but was able to trace root cause. Performance issue is present in ch.qos.logback.core.helpers.Transformer::escapeTags(final StringBuffer buf) method. They way it is replacing and encoding html characters is not efficient, each replace is doing System.arraycopy which was issue. Much better and correct way can be found in Log4j implementation of escapeTags as shown below. this only taken approx 280millis to process same 27MB vs 70mins taken by logback implementation. public static String escapeHtmlTags(String input) \{ if (Strings.isEmpty(input) || input.indexOf(34) == -1 && input.indexOf(38) == -1 && input.indexOf(60) == -1 && input.indexOf(62) == -1 && input.indexOf(39) == -1 ) \{ return input; } else \{ StringBuilder buf = new StringBuilder(input.length() + 6); int len = input.length(); for (int i = 0; i < len; ++i) \{ char ch = input.charAt(i); if (ch > '>') \{ buf.append(ch); } else if (ch == '<') \{ buf.append("<"); } else if (ch == '>') \{ buf.append(">"); } else if (ch == '&') \{ buf.append("&"); } else if (ch == '"') \{ buf.append("""); } else if (ch == '\'') \{ buf.append("'"); } else \{ buf.append(ch); } } return buf.toString(); } } -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1504) Logback has wrong index after restart
by QOS.CH (JIRA) 12 Feb '20

12 Feb '20

Adam created LOGBACK-1504: ----------------------------- Summary: Logback has wrong index after restart Key: LOGBACK-1504 URL: https://jira.qos.ch/browse/LOGBACK-1504 Project: logback Issue Type: Bug Components: logback-classic Affects Versions: 1.3.0-alpha5 Reporter: Adam Assignee: Logback dev list Helloo. I have problem with Logback (1.2.3, 1.3.0-alpha-5) The problem is then after restart application Logback not rolling files greather then 1000 index. Occurs files tmp. Example: {quote}log.2020-02-11.*1000*1711696676266552.tmp log.2020-02-11.*1001*1711696691083474.tmp {quote} last rolling file was: {quote}log.2020-02-11.*2831*.gz log.2020-02-11.*2832*.gz {quote} In my opinion logback always try increment index from 1000 but should be 2833. config: {{ <appender name="DEBUG_LOG_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>$\{PANIQUE_ROOT}/logs/log</file> <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy"> <fileNamePattern>$\{APP_ROOT}/logs/log.%d.%i.gz</fileNamePattern> <maxFileSize>100MB</maxFileSize> </rollingPolicy> <encoder> <pattern>%date [%thread] %X\{PROCESS_ID} %-5level %logger\{25} - %msg%n</pattern> </encoder> </appender> [https://stackoverflow.com/questions/60167669/logback-has-wrong-index-after-…] }} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

JDK 14 is now in the Release Candidate Phase
by Rory O'Donnell 10 Feb '20

10 Feb '20

Hi Ceki, *Per the JDK 14 schedule [1] , we are now in the Release Candidate Phase * The stabilization repository, jdk/jdk14, *is open for P1 bug fixes * per the JDK Release Process (JEP 3) [2]. All changes require approval via the Fix-Request Process [3]. For more details, see Mark Reinhold's email to jdk-dev mailing list [4] OpenJDK 14 EA build 36 is now available at http://jdk.java.net/14 * These early access, open source builds are provided under the GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. OpenJDK 15 EA build 9 is now available at http://jdk.java.net/15 * * * These early access, open source builds are provided under the GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. * Significant changes since the last availability email: o build 8 + JDK-8235783: DatagramSocket::disconnect should allow an implementation to throw UncheckedIOException + JDK-8237528: Inefficient compilation of Pattern Matching for instanceof # Reported by JaCoCo. o build 7 + JDK-8236105: DatagramSocket.send() and MulticastSocket.send() methods throw an IllegalArgumentException + JDK-8231422: Better serial filter handling + JDK-8227758: More valid PKIX processing + JDK-8230318: Better trust store usage + JDK-8234484: Add ability to configure third port for remote JMX Project Loom Early-Access Builds - Build 15-loom+3-20 (2020/1/27) * These early-access builds are provided under the GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. * These builds are intended for developers looking to "kick the tyres" and provide feedback on using the API or by sending bug reports. Warning: This build is based on an incomplete version of JDK 14 <http://openjdk.java.net/projects/jdk/14/>. Links to FOSDEM Videos that might be of interest: * https://twitter.com/OpenJDK/status/1225008387009785857 * https://twitter.com/OpenJDK/status/1225011154159833088 * https://twitter.com/OpenJDK/status/1225009792596488193 Regards, Rory [1] https://openjdk.java.net/projects/jdk/14/#Schedule [2] https://openjdk.java.net/jeps/3 [3] https://openjdk.java.net/jeps/3#Fix-Request-Process [4] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-February/003885.html -- Rgds, Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin, Ireland

1 0

[JIRA] (LOGBACK-1125) Enable the use of Janino together with logback in an OSGi environment
by QOS.CH (JIRA) 09 Feb '20

09 Feb '20

1 0

[JIRA] (LOGBACK-1001) JaninoEventEvaluatorBase should enable configuring of classloader in ScriptEvaluator
by QOS.CH (JIRA) 09 Feb '20

09 Feb '20

1 0

[JIRA] (LOGBACK-1503) TeeFilter breaks multipart processing on Spring Boot 2.2+
by QOS.CH (JIRA) 09 Feb '20

09 Feb '20

Gediminas Rimsa created LOGBACK-1503: ---------------------------------------- Summary: TeeFilter breaks multipart processing on Spring Boot 2.2+ Key: LOGBACK-1503 URL: https://jira.qos.ch/browse/LOGBACK-1503 Project: logback Issue Type: Bug Components: logback-access Affects Versions: 1.2.3 Environment: Spring Boot 2.2.4, Tomcat 9.0.30, Logback 1.2.3 TeeFilter registered like this: {{ {color:#808000}@Bean {color} {color:#000080}public {color}FilterRegistrationBean<TeeFilter> requestResponseFilter2() \{}} {{ FilterRegistrationBean<TeeFilter> filterRegBean = {color:#000080}new {color}FilterRegistrationBean<>();}} {{ filterRegBean.setFilter({color:#000080}new {color}TeeFilter());}} {{ filterRegBean.setName({color:#008000}"Logback access-logging request response filter"{color});}} {{ {color:#000080}return {color}filterRegBean;}} {{ }}} Reporter: Gediminas Rimsa Assignee: Logback dev list Priority: Minor *Symptom* Webapp fails to process multipart HTTP requests with the following exception: {quote} org.springframework.web.multipart.MultipartException: Failed to parse multipart servlet request; nested exception is java.io.IOException: org.apache.tomcat.util.http.fileupload.FileUploadException: Stream closed {quote} *Troubleshooting* - Multipart requests work when TeeFilter is disabled. - Multipart requests work when Spring Boot is downgraded to 2.1.12 (Tomcat still 9.0.30, Logback still 1.2.3) *Root cause* `TeeFilter` decorates incoming request with `TeeHttpServletRequest` that reads the input stream and closes it (see `TeeServletInputStream#duplicateInputStream`). Everything works as expected here. However, when `HttpServletRequest#getParts` is called later, `TeeHttpServletRequest` delegates it to the original request, which has its stream closed already, which results in the exception. *Workaround* Force loading of parts before request passes through `TeeFilter`. With Tomcat this is as simple as: {{{color:#000080}private static class {color}MultipartSafeTeeFilter {color:#000080}extends {color}TeeFilter \{}} {{ {color:#808000}@Override {color} {color:#000080}public void {color}doFilter(}} {{ ServletRequest request,}} {{ ServletResponse response,}} {{ FilterChain filterChain}} {{ ) {color:#000080}throws {color}IOException, ServletException \{}} {{ request.getParameter({color:#008000}"whatever"{color});}} {{ {color:#000080}super{color}.doFilter(request, response, filterChain);}} {{ }}} {{}}} -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-556) support groovy configuration in Context Selectors
by QOS.CH (JIRA) 08 Feb '20

08 Feb '20

1 0

[JIRA] (LOGBACK-1422) Deadlock with logging
by QOS.CH (JIRA) 07 Feb '20

07 Feb '20

1 0