- logback-dev - mailman3.qos.ch

[JIRA] (LOGBACK-1489) with SizeAndTimeBasedRollingPolicy totalSizeCap cannot be smaller than maxFileSize
by QOS.CH (JIRA) 05 Oct '20

05 Oct '20

1 0

[JIRA] Updates for LOGBACK-1528: Allow to change ExecutorServiceFactory
by QOS.CH (JIRA) 04 Oct '20

04 Oct '20

logback / LOGBACK-1528 [Open] Allow to change ExecutorServiceFactory ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1528 ============================== Issue created ------------------------------ Gael Lalire created this issue on 05/Oct/20 1:10 AM Summary: Allow to change ExecutorServiceFactory Issue Type: Improvement Affects Versions: 1.2.3 Assignee: Logback dev list Components: logback-core Created: 05/Oct/20 1:10 AM Priority: Major Reporter: Gael Lalire Description: I'm using logback in a classloader which should gets garbage collected. While logback.xml does not have a scanPeriod it is working fine. However with a scanPeriod logback will create a ScheduledExecutorService which prevent the classloader to be garbage collected. To work around that I created a weak scheduler service but in order to set it in logback core I need an extension point. Also please note that logback cannot clean its own thread on its own code, the cleanup code have to be in another classloader to allow the garbage collection. I created the extension point in [#496|https://github.com/qos-ch/logback/pull/496], I need a 1.2.4 release which still work with java 6. If you don't want to work again on 1.2.x, I still can release it myself in my repository. It may also have a sense in java9 versions, although I will not use them. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] (LOGBACK-783) Support for compressing logfiles with bzip2
by QOS.CH (JIRA) 03 Oct '20

03 Oct '20

1 0

[JIRA] (LOGBACK-1527) TeeFilter prints stack traces of uncaught exceptions to the standard erorr stream
by QOS.CH (JIRA) 02 Oct '20

02 Oct '20

1 0

[JIRA] Updates for LOGBACK-1527: TeeFilter prints stack traces of uncaught exceptions to the standard erorr stream
by QOS.CH (JIRA) 02 Oct '20

02 Oct '20

logback / LOGBACK-1527 [Open] TeeFilter prints stack traces of uncaught exceptions to the standard erorr stream ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1527 ============================== Issue created ------------------------------ Gediminas Rimsa created this issue on 02/Oct/20 6:51 PM Summary: TeeFilter prints stack traces of uncaught exceptions to the standard erorr stream Issue Type: Bug Affects Versions: 1.2.3 Assignee: Logback dev list Components: logback-access Created: 02/Oct/20 6:51 PM Environment: Logback 1.2.3 Spring boot webapp, with Logback configured to log to ConsoleAppender Priority: Minor Reporter: Gediminas Rimsa Description: h2. Problem In a webapp uncaught exceptions are handled (logged) by the servlet container (Tomcat in our case). However, Logback `TeeFilter` has the following code: {code:java} try { // ... (omitted) filterChain.doFilter(teeRequest, teeResponse); // ... (omitted) } catch (IOException e) { e.printStackTrace(); throw e; } catch (ServletException e) { e.printStackTrace(); throw e; } {code} This causes the stack trace to appear twice in the console (once logged by TeeFilter, and once by Tomcat). h2. Proposed solution # Remove `e.printStackTrace();` statements from `TeeFilter` - it has no responsibility of printing stack traces of exceptions it can not handle # Also replace `System.out.println` statements with logging to SLF4J API at INFO level I'd be happy to raise a PR for this if a new version of logback-access would be released soon after the fix. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

JDK 16 EA build 18 is now available
by Rory O'Donnell 02 Oct '20

02 Oct '20

Hi Ceki, OpenJDK 16 Early Access build 18**is now available at http://jdk.java.net/16 * These early-access , open-source builds are provided under the o GNU General Public License, version 2, with the Classpath Exception <http://openjdk.java.net/legal/gplv2+ce.html>. * Features: o JEPs proposed to target JDK 16 + JEP 376: ZGC: Concurrent Thread-Stack Processing <https://openjdk.java.net/jeps/376> + JEP 386: Alpine Linux Port <https://openjdk.java.net/jeps/386> + JEP 388: Windows/AArch64 Port <https://openjdk.java.net/jeps/388> o JEPs targeted to JDK 16, so far: + JEP 338: Vector API (Incubator) <https://openjdk.java.net/jeps/338> + JEP 347: Enable C++14 Language Features <https://openjdk.java.net/jeps/347> + JEP 357: Migrate from Mercurial to Git <https://openjdk.java.net/jeps/357> + JEP 369: Migrate to GitHub <https://openjdk.java.net/jeps/369> + JEP 387: Elastic Metaspace <https://openjdk.java.net/jeps/387> * Release Notes are available at http://jdk.java.net/16/release-notes ** * Changes in recent builds that maybe of interest: o Build 17 + JDK-8247281: Object monitors no longer keep strong references to their associated object + JDK-8202473: A type variable with multiple bounds does not correctly place type annotation # Reported by ByteBuddy + JDK-8234808: jdb quoted option parsing broken # Reported by Apache Tomcat o Build 16 + JDK-8172366: SUN, SunRsaSign, and SunEC Providers Supports SHA-3 Based Signature Algorithms + JDK-8244706: GZIPOutputStream now sets the GZIP OS Header Field to the correct default value * Quality Report for September 2020 was published here [1]. Thanks to everyone who contributed by creating features or enhancements, logging bugs, or downloading and testing the early-access builds. *__* Rgds,Rory [1] https://wiki.openjdk.java.net/display/quality/Quality+Outreach+report+Septe… -- Rgds, Rory O'Donnell Quality Engineering Manager Oracle EMEA, Dublin, Ireland

1 0

[JIRA] (LOGBACK-1526) Logback-access pollutes logs with binary file content
by QOS.CH (JIRA) 02 Oct '20

02 Oct '20

1 0

[JIRA] Updates for LOGBACK-1526: Logback-access pollutes logs with binary file content
by QOS.CH (JIRA) 02 Oct '20

02 Oct '20

logback / LOGBACK-1526 [Open] Logback-access pollutes logs with binary file content ============================== Here's what changed in this issue in the last few minutes. This issue has been created This issue is now assigned to you. View or comment on issue using this link https://jira.qos.ch/browse/LOGBACK-1526 ============================== Issue created ------------------------------ Gediminas Rimsa created this issue on 02/Oct/20 9:11 AM Summary: Logback-access pollutes logs with binary file content Issue Type: Bug Affects Versions: 1.2.3 Assignee: Logback dev list Components: logback-access Created: 02/Oct/20 9:11 AM Environment: Logback 1.2.3 Logback-access config: {code:java} <configuration> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> <evaluator class="ch.qos.logback.access.net.URLEvaluator"> <URL>/ping</URL> </evaluator> <OnMismatch>NEUTRAL</OnMismatch> <OnMatch>DENY</OnMatch> </filter> <encoder> <pattern>%t{ISO8601} [%I] %requestURL | status code: %statusCode | elapsed time: %elapsedTime | request: %magenta(%requestContent) | response: %cyan(%responseContent)</pattern> </encoder> </appender> <appender-ref ref="STDOUT"/> </configuration> {code} Priority: Major Reporter: Gediminas Rimsa Description: h2. Problem We have a Spring boot app exposing a RESTful API that runs on embedded Tomcat (latest versions) and uses logback-access (also latest 1.2.3). Recently I noticed that access logs include raw binary content of images/PDF files. Example from logs: {code:java} POST /projects/projectId/images HTTP/1.1 | status code: 200 | elapsed time: 664 | request: GIF89a� d �[[ most content ommitted ]]g�� w�� ; | response: {"id":"877f2338-293d-403b-99fb-09fc631ce7b3"} GET /projects/projectid/images/877f2338-293d-403b-99fb-09fc631ce7b3 HTTP/1.1 | status code: 200 | elapsed time: 538 | request: | response: [IMAGE CONTENTS SUPPRESSED] {code} As you see, binary content suppression is incomplete. This is how it works currently for different content types: || ||image/*||any other binary|| |Request|{color:#de350b}logged{color}|{color:#de350b}logged{color}| |Response|{color:#00875a}suppressed{color}|{color:#de350b}logged{color}| For us it is a problem, as our application has to regularly deal with large (20+ MB) ZIP and PDF files, h2. Cause Looking at the code, image content suppression happens in `+ch.qos.logback.access.spi.AccessEvent#getResponseContent+`, but it only checks if content type starts with `_image/_`. Equivalent code in `+ch.qos.logback.access.spi.AccessEvent#getRequestContent+` is not present. I traced response image content suppression was added with this commit (all the way back in 2007): [https://github.com/qos-ch/logback/commit/69290e182f8db6589eadd5a3c485a37255…] h2. Workaround None, except for ugly classloading hacks or implementing a custom `AccessEvent` that overrides `getRequestContent` and `getResponseContent`. h2. Resources Related thread (with no responses) in logback-user mailing list: http://mailman.qos.ch/pipermail/logback-user/2020-September/005086.html ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] (LOGBACK-1508) Dependency check-framework @NotNull conflict with validation-api
by QOS.CH (JIRA) 01 Oct '20

01 Oct '20

1 0

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

23 Sep '20

1 0