February 2020 - logback-dev

[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

[JIRA] (LOGBACK-1502) Janino no longer works with 1.3.0-alpha5
by QOS.CH (JIRA) 07 Feb '20

07 Feb '20

Jeremy Landis created LOGBACK-1502: -------------------------------------- Summary: Janino no longer works with 1.3.0-alpha5 Key: LOGBACK-1502 URL: https://jira.qos.ch/browse/LOGBACK-1502 Project: logback Issue Type: Bug Components: logback-classic, logback-core Affects Versions: 1.3.0-alpha5 Environment: janino stopped working with this release resulting in creation of unknown log location files. It works up through alpha4 without issues and no changes. Can this please be fixed? Reporter: Jeremy Landis Assignee: Logback dev list -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1501) Make checker framework which is really, really old, optional
by QOS.CH (JIRA) 07 Feb '20

07 Feb '20

Jeremy Landis created LOGBACK-1501: -------------------------------------- Summary: Make checker framework which is really, really old, optional Key: LOGBACK-1501 URL: https://jira.qos.ch/browse/LOGBACK-1501 Project: logback Issue Type: Bug Components: logback-classic Affects Versions: 1.3.0-alpha5 Environment: This release started requiring a really old checker framework that conflicts with newer one as group id changed. If the really old version is necessary, please make it optional. Reporter: Jeremy Landis Assignee: Logback dev list -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1410) Make com.sun.mail:javax.mail optional
by QOS.CH (JIRA) 07 Feb '20

07 Feb '20

1 0

[JIRA] (LOGBACK-1500) SizeAndTimeBasedRollingPolicy misbehavior after %i index reaches 999
by QOS.CH (JIRA) 06 Feb '20

06 Feb '20

George Yanev created LOGBACK-1500: ------------------------------------- Summary: SizeAndTimeBasedRollingPolicy misbehavior after %i index reaches 999 Key: LOGBACK-1500 URL: https://jira.qos.ch/browse/LOGBACK-1500 Project: logback Issue Type: Bug Components: logback-classic, logback-core Affects Versions: 1.2.3 Environment: OS: Ubuntu 18.04.4 LTS java: java version "1.8.0_181" Java(TM) SE Runtime Environment (build 1.8.0_181-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode) Reporter: George Yanev Assignee: Logback dev list Attachments: logback-test.rar I'm using SizeAndTimeBasedRollingPolicy. When '%i' file index reaches 999 it stops deleting the old files and totalSizeCap is not respected any more. This soon leads to disk full issues (as logging in my case was fast enough) I'm attaching a java example with a simple logging configuration to demonstrate this. You have to run it just for a couple off minutes to reach file index 999 Use maven install to build. Untar the generated tar.gz file to some place and run the example with java -jar testartifact-1.0.0-20200206.jar -- This message was sent by Atlassian JIRA (v7.3.1#73012)

1 0

[JIRA] (LOGBACK-1406) Seems all threads blocked
by QOS.CH (JIRA) 04 Feb '20

04 Feb '20

1 0