Matt Sicker

So far, I've managed to migrate most of these things. I had to disable some tests for now, though, as they significantly abuse internal details of the legacy way of...

Although some of them might work properly after I try to figure out yet another architecture for the JUnit 5 extensions since splitting them up into multiple annotations doesn't seem...

Extracted https://github.com/apache/logging-log4j2/issues/2204 from work done in previous attempt at this issue.

We've got a couple sides to metrics: defining metrics within Log4j itself, and direct support for OpenTelemetry APIs. As Log4j itself does not depend on anything besides the `java.base` module,...

I like this idea because it also supports use of other file system implementations based on what the user has installed. That could also be useful in tests if we...

Also a few new places in the DI system (some of which is difficult to express within the limitations of the Java type system).

In fact, there are numerous places in the DI system abusing this. I'd be open to cleaning that up as it might also allow for the `Key` class to be...

If you mean the general Spring Boot properties `logging.level.[logger-name]: off`, then this is specific to however Spring decided to handle this particular YAML parser. If this is for a `log4j2.yml`...

Got it; thanks for the context! I think we could make `Level.valueOf(false)` equivalent to `Level.OFF`.

Does this deadlock coincide with the hourly log file rollover you configured? I wonder if there's a race condition here between incoming log events and the rollover process.