Forgot to expand the webapps/WEB-INF/lib jars as well… root@8ad4f1dcd125:/usr/local/tomcat# find ./ -type f -name logging.properties ./conf/logging.properties ./webapps/corporativo-comum/WEB-INF/lib/org/springframework/boot/logging/java/logging.properties
So there’s springboot's logging.properties. Should it really affect tomcat’s logging? > Em 29 de set. de 2023, à(s) 16:18, Alcides Moraes <alcides.n...@gmail.com> > escreveu: > > Hi Christopher, > > Thanks for the suggestion, we do add some jars to Tomcat lib (mainly > Prometheus, Hazelcast) > I expanded every jar inside tomcat/lib and ran a find command. > > root@05ae85e03d7d:/# find ./ -type f -name logging.properties > ./usr/local/tomcat/conf/logging.properties > ./opt/java/openjdk/conf/logging.properties > > The only other logging.properties is the one from JDK. I tried changing its > content just to see if that was what was being used, but it had no effect. > > So the issue still remains, but we have worked around it by configuring > tomcat to use log4j2 as per this documentation: > https://logging.apache.org/log4j/2.x/log4j-appserver.html > > With this and the log4j-jul bridge, all logs are now formatted correctly. > >> Em 29 de set. de 2023, à(s) 08:56, Christopher Schultz >> <ch...@christopherschultz.net> escreveu: >> >> Alcides, >> >> On 9/28/23 14:55, Alcides Moraes wrote: >>> Hello everyone, >>> I’m new to the list even though I’ve been a Java web developer for many >>> years, I’ve never had the need to post here, but this time I think I may >>> have stumbled upon a bug, and nothing turns up online on this issue. >>> We’re migrating our containerized legacy webapps from Java 8/11 to Java 17. >>> They all ran on Tomcat 8.5, now we’re upgrading to 9. >>> We customize a base image from tomcat:9.0.80-jdk17-temurin-focal. Amongst >>> other things, we add a logging.properties to customize tomcat’s log format. >>> This always worked well, but after our upgrade to Java 17, there’s a weird >>> behavior that has stumped us. >>> During Tomcat’s startup, the logs are formatted correctly as we specify in >>> logging.properties. However, after a certain point in the logs, the logs >>> revert to the “default” JUL/JULI format. >>> Apart from this, everything works as expected. But we need the formatted >>> logs because we parse them with LogStash and OpenSearch. >>> Here’s an excerpt of the logs when this happens: >>> local-corporativo-comum-1 | 2023-09-27T18:57:34.188 INFO >>> [org.apache.coyote.http11.Http11NioProtocol] (thread-1) Initializing >>> ProtocolHandler ["http-nio-8080"] >>> local-corporativo-comum-1 | 2023-09-27T18:57:34.266 INFO >>> [org.apache.catalina.startup.Catalina] (thread-1) Server initialization in >>> [3419] milliseconds >>> local-corporativo-comum-1 | 2023-09-27T18:57:34.606 INFO >>> [com.hazelcast.config.UrlXmlConfig] (thread-1) Configuring Hazelcast from >>> 'file:/usr/local/tomcat/conf/hazelcast-local.xml'. >>> local-corporativo-comum-1 | 2023-09-27T18:57:36.775 INFO >>> [org.apache.catalina.core.StandardService] (thread-1) Starting service >>> [Catalina] >>> local-corporativo-comum-1 | 2023-09-27T18:57:36.789 INFO >>> [org.apache.catalina.core.StandardEngine] (thread-1) Starting Servlet >>> engine: [Secure Web Server] >>> local-corporativo-comum-1 | 2023-09-27T18:57:36.863 INFO >>> [org.apache.catalina.startup.HostConfig] (thread-1) Diretório de instalação >>> da aplicação web [/usr/local/tomcat/webapps/corporativo-comum] >>> local-corporativo-comum-1 | 2023-09-27T18:57:52.647 INFO >>> [br.leg.senado.util.tomcat.DataSourceFactory] (thread-1) Criando instância >>> do datasource corporativo-comumDS >>> local-corporativo-comum-1 | set. 27, 2023 6:57:55 PM >>> br.leg.senado.util.tomcat.DataSourceFactory getObjectInstance >>> local-corporativo-comum-1 | INFORMAÇÕES: Criando instância do datasource >>> monitoraaplDS >>> local-corporativo-comum-1 | set. 27, 2023 6:57:55 PM >>> org.apache.catalina.core.ApplicationContext log >>> local-corporativo-comum-1 | INFORMAÇÕES: 1 Spring >>> WebApplicationInitializers detected on classpath >>> local-corporativo-comum-1 | set. 27, 2023 6:57:55 PM >>> org.apache.catalina.core.ApplicationContext log >>> local-corporativo-comum-1 | INFORMAÇÕES: Initializing Spring root >>> WebApplicationContext >>> local-corporativo-comum-1 | 18:57:55.751 [main] INFO >>> org.springframework.web.context.ContextLoader - Root WebApplicationContext: >>> initialization started >>> The red text is tomcat logging using the defaults (which localize log >>> levels to our locale which is pt-br). >>> I suspect that the point where this happens is when the webapp is being >>> initialized. A webapp shouldn’t be able to interfere with Tomcat’s log >>> behavior, right? >>> The webapp does not use JUL, it uses logback, and it logs correctly during >>> and after its startup. >>> The logs you see @ 18:57:52 that says “Criando instância...” are of custom >>> datasource resources specified in a context.xml file. >>> They have a custom factory class, passed from a custom jar in tomcat's >>> class path. >>> This jar has worked and logged correctly since ever, we didn’t even >>> recompile them to Java 17, we kept them as they were (Java 8). >>> I’ve tried changing the way this component logs, by calling org.apache.juli >>> instead of java.util.logging, removed all logging whatsoever, but nothing >>> changes this behavior. >>> Any suggestions on debugging this? If you need more info don’t hesitate to >>> ask. >>> Thanks in advance for any help on this. >> >> I feel like I've heard of things like this happening before. It had >> something to do with an application re-initializing and having a private >> logging.properties file which ended up updating the global logging >> configuration. >> >> Can you search the entire (container's) disk for logging.properties files >> /and also all the JAR files you are using/ to see if there is a stray file >> somewhere that could be picked-up at some point after initial boot? >> >> -chris >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >
