https://bz.apache.org/bugzilla/show_bug.cgi?id=66178
--- Comment #4 from Joe Jackson <midnjack...@gmail.com> --- Thanks for the quick feedback. I was also concerned about the readability trade-off. For my use case, we have a big focus on the garbage generation of the app and this showed up as a contributor so I figured it would be worth bringing up. We are using java 11.13 and tomcat 8.5.72. No worries if you don't think the trade-off has value because of newer compilers. I do have a concern about the comments on TTL and it is something I looked into because as far as I can tell (maybe something is misconfigured on my end) we do validate regardless of it being returned from the cache or not. Increasing the TTL did not help with garbage generation. A better re-write may be a method to target a single jar instead of having to scan all of them. In our use case, I believe we already know the path to the jar which contains the resource we are trying to access. Here is the code showing we validate even when we get from the cache. https://github.com/apache/tomcat/blob/8.5.x/java/org/apache/catalina/webresources/Cache.java#L69 Here is the stack trace, note line 69 is the one where we did find the cached resource. getResourceInternal:280, StandardRoot (org.apache.catalina.webresources) validateResource:128, CachedResource (org.apache.catalina.webresources) getResource:69, Cache (org.apache.catalina.webresources) getResource:215, StandardRoot (org.apache.catalina.webresources) getClassLoaderResource:224, StandardRoot (org.apache.catalina.webresources) getResourceAsStream:1168, WebappClassLoaderBase (org.apache.catalina.loader) -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
