Memory when redeploying

[ezinine]

Describe the bug
As far as I can see there is a leak of ThreadLocal, when deploying into a standalone tomcat, that is not restarted after redeployment. Is it supposed to be supported?

I have tried to ensure close-methods is called. My understanding of the reason is, that tomcat deploys in its own long lived thread - we we do log something, therefore it does add to stuff to a couple of threadlocals.

Since this thread outlives the application, it holds references to it - then stuff is kept in memory

The threadlocals in question in:

• OmitEmptyFieldWriter.filteringGenerators
• AbstractCompositeJsonFormatter.threadLocalJsonFormatter.threadLocal
• CompositeJsonEncoder.threadLocalBuffer.threadLocal

To Reproduce
Steps to reproduce the behavior:

1. Use this logback.xml configuration
   `

<root level="DEBUG">
  <appender-ref ref="FILE"/>
</root>

${LOG_FILE} true @timestamp yyyy-MM-dd'T'HH:mm:ss.SSSXXX level logger_name message true { "traceId": "%mdc{traceId}", "AuditUniid": "%mdc{uniid}", "exception.exception_message": "%ex{short}", "exception.stacktrace": "%rEx{50}" } ` 2. Deploy application in standalone tomcat 3. Undeploy application from standalone tomcat - now tomcat says ThreadLocals are leftover **Expected behavior** No logging of leftover ThreadLocals, and everything from the application can be released on garbage collect

• what output did you expect

Additional context
Add any other context about the problem here.

• logstash-logback-encoder version: 8.1
• logback version: 1.5.8
• jackson version: 2.19
• java version: 21.0.6