[logback-dev] [JIRA] (LOGBACK-1526) Logback-access pollutes logs with binary file content

[QOS.CH (JIRA)]

Title: Message Title

Gediminas Rimsa commented on LOGBACK-1526   Re: Logback-access pollutes logs with binary file content The ugly workaround I mentioned, in case anyone is in desperate need of a quick solution. We are using `net.rakugakibox.spring.boot:logback-access-spring-boot-starter` library to set up logback-access in our Spring Boot (v2.3.3) app. The class we are copying into our project is `TomcatLogbackAccessEvent` and in it, we are adding the following code: @Override public String getRequestContent() { if (isSuppressedContentType(getRequest().getContentType())) { return "[CONTENT SUPPRESSED]"; } return super.getRequestContent(); } @Override public String getResponseContent() { if (isSuppressedContentType(getResponse().getContentType())) { return "[CONTENT SUPPRESSED]"; } return super.getResponseContent(); } private boolean isSuppressedContentType(String contentType) { return contentType != null && ( contentType.startsWith("image/") || contentType.equals("application/pdf") || contentType.equals("application/zip") ); } We place this class in the application, but keep the same package (so that qualified class name remains the same as in `logback-access-spring-boot-starter` library). Then once our app starts it is our modified version of that access event class that gets loaded instead of the one provided in the library (this is because classes in the app itself have higher classloading priority than those located in libs). It works, but it's fragile because we now have a bunch of copied and modified code that we have to manually keep in sync when we are updating that third party library. Add Comment   This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

_______________________________________________
logback-dev mailing list
logback-dev@qos.ch
http://mailman.qos.ch/mailman/listinfo/logback-dev