ppkarwasz commented on issue #3504: URL: https://github.com/apache/logging-log4j2/issues/3504#issuecomment-2696353015
> > If `o.a.l.l.spi.ExtendedLogger` were to dynamically appear in a classloader, but the classloader already attempted to load the class, a NoClassDefFoundError will be thrown. Sorry, this statement is incorrect: classloaders don't have a negative cache of classes that don't exist. However, Tomcat introduced one in its October 2024 releases (see [9.0.97 release notes](https://tomcat.apache.org/tomcat-9.0-doc/changelog.html#Tomcat_9.0.97_(remm)) for example): > Cache not found results when searching for web application class loader resources. This addresses performance problems caused by components such as `java.sql.DriverManager` which, in some circumstances, will search for the same class repeatedly. In a large web application this can cause performance problems. The size of the cache can be controlled via the new `notFoundClassResourceCacheSize` on the StandardContext. (markt) This is why your code fails on newer Tomcat releases: by calling `Class.forName("org.apache.logging.log4j.spi.ExtendedLogger")`, Tomcat will cache the error. As I mentioned above, testing for `o.a.l.l.spi.ExtendedLogger` is something libraries like `spring-jcl` do. I didn't test it, but setting `notFoundClassResourceCacheSize` to `0`, should solve your problem: ```xml <Context notFoundClassResourceCacheSize="0"> ... </Context> ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@logging.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
