вт, 6 авг. 2024 г. в 12:44, Mark Thomas <ma...@apache.org>: > > On 06/08/2024 09:56, Rémy Maucherat wrote: > > On Tue, Aug 6, 2024 at 10:19 AM Mark Thomas <ma...@apache.org> wrote: > >> > >> The current TLD scanner logs the following message if JARs are scanned > >> but not TLDs are found: > >> > >> <quote> > >> At least one JAR was scanned for TLDs yet contained no TLDs. Enable > >> debug logging for this logger for a complete list of JARs that were > >> scanned but no TLDs were found in them. Skipping unneeded JARs during > >> scanning can improve startup time and JSP compilation time. > >> </quote> > >> > >> However, the detailed log messages are now logged at trace level. This > >> creates a couple of issues: > >> > >> 1. The message above is incorrect > >> > >> 2. With the message above corrected, and the correct logger level set, > >> the messages still are not displayed because the logger handlers are > >> configured to drop all messages below DEBUG level. > >> > >> > >> I'd like to propose the following changes: > >> > >> - Change the default handler level to ALL. This should not change the > >> current log output but should ensure messages are not dropped if a > >> logger is explicitly configured to output trace (FINEST) messages. > >> > >> - Change the message above to say "Enable trace logging..." > >> > >> > >> The only issue is that all the translations would need to be updated. I > >> can mark them as fuzzy in POEditor which should mean they get flagged > >> for review/update but whether anyone will update them is a different > >> question. The alternative is to switch the TLDScanner back to logging at > >> debug level. > >> > >> Thoughts? > > > > So I downgraded these because they did not really look like debug to > > me, but more like traces. The separation between the two is quite > > subtle ;) Sorry for the trouble ... > > No worries. > > > So instead of doing too much for this, and since this log is likely > > useful, I would upgrade back the noTldInJar to debug since most likely > > admin action is needed. > > OK. That is a much simpler solution. > > > Otherwise +1 for the idea of enabling ALL by default, there would be > > less fiddling around when trying to enable trace. > > Exactly. > > I'll get those changes done.
+1 Looking at other usages of JarScannerCallback, e.g. o.a.catalina.startup.ContextConfig, I see no obvious problem. There is one message about DEBUG level (contextConfig.sci.info) but it is about a different situation (whether a stacktrace is being printed), and it is OK - it uses log.debug() there. Update the documentation? https://tomcat.apache.org/tomcat-11.0-doc/logging.html a) It already mentions the "ALL" level. - OK quote: "To enable debug logging for part of Tomcat's internals, you should configure both the appropriate logger(s) and the appropriate handler(s) to use the FINEST or ALL level. e.g.: " b) There are two configuration samples (a global one, and one for the examples web application), quote: "Example logging.properties file to be placed in $CATALINA_BASE/conf: " - Update to s/FINE/ALL/. - The sample uses a FileHandler, but we are using AsyncFileHandler nowadays. quote: "Example logging.properties for the servlet-examples web application to be placed in WEB-INF/classes inside the web application" - The same as above - ConsoleHandler is missing the ".encoding" setting. c) BTW, in "Considerations for production usage" it says quote: "The handlers by default use the system default encoding to write the log files. It can be configured with encoding property. See Javadoc for details." I think it is still true (as it actually talks about programmed defaults), but our default configuration has been configured to use "*.encoding = UTF-8" on all handlers, including the ConsoleHandler. (At the time when that phrase was written, ConsoleHandler was configured with the system encoding.) Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
