Re: Wrong content-type for CSS files since 8.5.37 / 9.0.14
Am 27.12.18 um 21:34 schrieb Rémy Maucherat: > On Thu, Dec 27, 2018 at 9:30 PM Mark Thomas wrote: > >> On December 26, 2018 9:49:00 PM UTC, "i...@flyingfischer.ch" < >> i...@flyingfischer.ch> wrote: >>> Tomcat versions 8.5.37 and 9.0.14 seem to serve CSS files embedded in a >>> webapp as >>> >>> content-type: text/html;charset=UTF-8 >>> >>> instead of >>> >>> content-type: text/css;charset=UTF-8 >>> >>> This causes the browser (FF) not to interpret the CSS. >>> >>> I suspect the listed change in changelog of 8.5.36: "The default >>> Servlet >>> should not override a previously set content-type. (remm)" >> Sounds likely. >> >> Whatever part of the app is setting the incorrect content type (probably a >> filter) needs to be fixed. >> > Yes, I also prefer keeping the new behavior, which was suggested by > Christopher. Worst case scenario there should be a new init-param. > > Rémy > I could get it fixed by disabling a filter in the (legacy) app, which did set a hardcoded content-type to UTF-8. Markus - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 9.0.14 startup fails
On Thu, Dec 27, 2018 at 4:35 PM 李洋 wrote: > > https://stackoverflow.com/questions/28776520/systemd-service-for-jar-file-gets-operation-timed-out-error-after-few-minues-o > this issue is familiar your‘s，hope this answe wil help you！ > > Steve Demy 于2018年12月27日周四 下午12:20写道： > > > Tomcat 9.0.14 startup fails, or at least is not recognized as complete by > > Ubuntu’s systemd which times out: > > > > Dec 25 05:19:09 vps169399 catalina.sh[9716]: 25-Dec-2018 05:19:09.586 > INFO > > [main] org.apache.catalina.startup.Catalina.start Server startup in > [1,868] > > milliseconds > > Dec 25 05:20:34 vps169399 systemd[1]: tomcat.service: Start operation > > timed out. Terminating. > > > > A stop operation then fails (port 8005 held by the hung start operation?) > > and tomcat is killed by the OS. > > > > Systemd then restarts Tomcat 10 seconds later resulting in a start/stop > > loop. After a system reboot, one start operation will proceed normally, > > but any restart results in the start/stop loop. There are no webapps > > involved except the tomcat packed ones. > > > > Tomcat 9.0.13 works perfectly with identical installation and > > configuration. What is systemd is expecting that it is not getting from > > 9.0.14? Any clue will be much appreciated. > > > > The systemd script and full startup log are enclosed below, which > contains > > details of the environment. > > > > [Unit] > > Description=Apache Tomcat Web Application Container > > After=network.target > > > > [Service] > > Type=forking > > > > Environment=JAVA_HOME=/usr/lib/jvm/jdk-11.0.1 > > Environment=CATALINA_PID=/opt/tomcat/temp/tomcat.pid > > Environment=CATALINA_HOME=/opt/tomcat > > Environment=CATALINA_BASE=/opt/tomcat > > Environment='JAVA_OPTS=-Djava.awt.headless=true > > -Djava.security.egd=file:/dev/./urandom' > > Environment=LD_LIBRARY_PATH=/opt/tomcat/lib > > Environment='CATALINA_OPTS=-Xms1024m -Xmx1024m' > > > > ExecStart=/opt/tomcat/bin/startup.sh > > ExecStop=/opt/tomcat/bin/shutdown.sh > > > > User=tomcatuser > > Group=tomcatgroup > > UMask=0007 > > RestartSec=10 > > Restart=always > > > > [Install] > > WantedBy=multi-user.target > > > > > > Complete startup log: > > > > -- Unit tomcat.service has begun starting up. > > Dec 25 05:19:04 vps169399 catalina.sh[9716]: NOTE: Picked up > > JDK_JAVA_OPTIONS: --add-opens=java.base/java.lang=ALL-UNNAMED > > --add-opens=java.base/java.io=ALL-UNNAMED > > --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED > > Dec 25 05:19:06 vps169399 catalina.sh[9716]: 25-Dec-2018 05:19:06.362 > INFO > > [main] org.apache.catalina.startup.VersionLoggerListener.log Server > version > > name: Apache Tomcat/9.0.14 > > Dec 25 05:19:06 vps169399 catalina.sh[9716]: 25-Dec-2018 05:19:06.376 > INFO > > [main] org.apache.catalina.startup.VersionLoggerListener.log Server > built: > > Dec 6 2018 21:13:53 UTC > > Dec 25 05:19:06 vps169399 catalina.sh[9716]: 25-Dec-2018 05:19:06.380 > INFO > > [main] org.apache.catalina.startup.VersionLoggerListener.log Server > version > > number: 9.0.14.0 > > Dec 25 05:19:06 vps169399 catalina.sh[9716]: 25-Dec-2018 05:19:06.381 > INFO > > [main] org.apache.catalina.startup.VersionLoggerListener.log OS Name: > > Linux > > Dec 25 05:19:06 vps169399 catalina.sh[9716]: 25-Dec-2018 05:19:06.382 > INFO > > [main] org.apache.catalina.startup.VersionLoggerListener.log OS Version: > > 4.15.0-43-generic > > Dec 25 05:19:06 vps169399 catalina.sh[9716]: 25-Dec-2018 05:19:06.383 > INFO > > [main] org.apache.catalina.startup.VersionLoggerListener.log > Architecture: > > amd64 > > Dec 25 05:19:06 vps169399 catalina.sh[9716]: 25-Dec-2018 05:19:06.383 > INFO > > [main] org.apache.catalina.startup.VersionLoggerListener.log Java Home: > > /usr/lib/jvm/jdk-11.0.1 > > Dec 25 05:19:06 vps169399 catalina.sh[9716]: 25-Dec-2018 05:19:06.384 > INFO > > [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Version: > > 11.0.1+13 > > Dec 25 05:19:06 vps169399 catalina.sh[9716]: 25-Dec-2018 05:19:06.384 > INFO > > [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor: > > Oracle Corporation > > Dec 25 05:19:06 vps169399 catalina.sh[9716]: 25-Dec-2018 05:19:06.386 > INFO > > [main] org.apache.catalina.startup.VersionLoggerListener.log > > CATALINA_BASE: /opt/tomcat > > Dec 25 05:19:06 vps169399 catalina.sh[9716]: 25-Dec-2018 05:19:06.386 > INFO > > [main] org.apache.catalina.startup.VersionLoggerListener.log > > CATALINA_HOME: /opt/tomcat > > Dec 25 05:19:06 vps169399 catalina.sh[9716]: 25-Dec-2018 05:19:06.387 > INFO > > [main] org.apache.catalina.startup.VersionLoggerListener.log Command line > > argument: --add-opens=java.base/java.lang=ALL-UNNAMED > > Dec 25 05:19:06 vps169399 catalina.sh[9716]: 25-Dec-2018 05:19:06.388 > INFO > > [main] org.apache.catalina.startup.VersionLoggerListener.log Command line > > argument: --add-opens=java.base/java.io=ALL-UNNAMED > > Dec 25 05:19:06 vps169399 catalina.sh[9716]: 2
Re: lingering mysql connections
This is a bit of a lead but it doesn't entirely solve it. It's only cleaning up connections to one of the datasources, I still have connections for 2 of them duplicated :( If I get a chance I'll go digging some more based on the SO rabbit hole, but I can mitigate the problem by restarting tomcat (since it's really only a sandbox issue where I do a lot of redeploys) Cheers Chris On Fri, Dec 14, 2018 at 3:00 AM Greg Huber wrote: > > I resolved the same using this link > > https://stackoverflow.com/questions/11872316/tomcat-guice-jdbc-memory-leak > > I created the ContextFinalizer to cleanup on shut down. > > Also, I had loads of strange sql issues which were resolved by switching to > maria db. > > Cheers Greg > > On Thu, 13 Dec 2018 at 20:51, Chris Cheshire wrote: > > > Tomcat 9.0.12, Debian, MySQL Server 5.7.23, Connector/J 5.1.46 > > > > I am trying to fix a lingering database connection problem. When I > > reload a context via the tomcat manager, connections to the > > datasources are not being released in mysql. They are still on the 30 > > second activity cycle from the eviction thread. I can see this via > > 'show processlist' in the mysql client - the 'time' column resets at > > 30, and each connection has unique process ids that I can track per > > reload. > > > > I have tomcat home and base split (multiple instances of tomcat across > > different users), with the connector/j jar in tomcat_base/lib. > > > > In my webapp's META-INF/context.xml I have 3 different datasources, > > config, data, sched. All have configuration like : > > > >> auth="Container" > > type="javax.sql.DataSource" > > driverClassName="com.mysql.jdbc.Driver" > > > > url="jdbc:mysql://localhost:3306/$DBNAME$?useUnicode=true&characterEncoding=utf8&useSSL=false" > > factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" > > username="$USER$" > > password="$PASSWORD$" > > maxActive="2" > > maxIdle="1" > > minIdle="1" > > initialSize="1" > > maxWait="3" > > removeAbandoned="true" > > removeAbandonedTimeout="60" > > logAbandoned="true" > > validationQuery="/* ping */" > > testOnBorrow="true" > > testWhileIdle="true" > > timeBetweenEvictionRunsMillis="3" > > defaultAutoCommit="false" > > defaultIsolation="READ_COMMITTED" /> > > > > Connections are obtained via > > > > Connection dbConn = ((DataSource)new > > InitialContext().lookup(resourceName)).getConnection() > > > > Connections are all closed via > > > > dbConn.close() > > > > (Simplified greatly, there's convenience methods with exception > > handling in there) > > > > > > > > In contextDestroyed() of a ServletContextListener I am calling > > > > AbandonedConnectionCleanupThread.checkedShutdown(); > > > > I have an initialization servlet that must be manually called before > > the webapp is fully online - it is used to load encrypted > > configuration from the conf datasource. It does not touch the data > > datasource, only conf and sched by virtue of starting the quartz > > scheduler which is configured to use this datasource. > > > > My observation are : > > * It doesn't matter what order I declare the datasources, they are > > always getting opened in the order sched, conf, data (judging by > > increased thread/process ids in mysql). > > * When I start tomcat, I get 3 open connections in mysql, 1 to each of > > the databases referenced by the datasources. If I immediately reload > > via the manager, all 3 connections are destroyed and 3 new ones are > > opened. > > * Once I call the initialization servlet, and subsequently reload the > > web app via the manager, previous connections to conf and sched are > > still open in mysql, as well as new ones > > * If I access any part of the web app that uses the data datasource, > > those connections now also linger. > > * Once I stop tomcat (and the JVM) all lingering connections are > > closed in mysql. > > * If I put the connector/j jar in my WEB-INF/lib instead of > > tomcat_base/lib, I get the following warning on reload/shutdown > > > > 13-Dec-2018 20:19:53.968 WARNING [ajp-nio-8019-exec-3] > > org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesJdbc > > The web application [ct] registered the JDBC driver > > [com.mysql.jdbc.Driver] but failed to unregister it when the web > > application was stopped. To prevent a memory leak, the JDBC Driver has > > been forcibly unregistered. > > > > * There are no warnings or errors in catalina.out about abandoned > > connections during runtime, reload or shutdown of the tomcat instance. > > I have every connection being closed after use. (I have seen the > > warnings when I have made a code mistake however, so the thread is > > doing its job). > > * If I remove the abandoned connection and eviction thread > > configuration entir
Re: Wrong content-type for CSS files since 8.5.37 / 9.0.14
On Thu, Dec 27, 2018 at 9:30 PM Mark Thomas wrote: > On December 26, 2018 9:49:00 PM UTC, "i...@flyingfischer.ch" < > i...@flyingfischer.ch> wrote: > >Tomcat versions 8.5.37 and 9.0.14 seem to serve CSS files embedded in a > >webapp as > > > >content-type: text/html;charset=UTF-8 > > > >instead of > > > >content-type: text/css;charset=UTF-8 > > > >This causes the browser (FF) not to interpret the CSS. > > > >I suspect the listed change in changelog of 8.5.36: "The default > >Servlet > >should not override a previously set content-type. (remm)" > > Sounds likely. > > Whatever part of the app is setting the incorrect content type (probably a > filter) needs to be fixed. > Yes, I also prefer keeping the new behavior, which was suggested by Christopher. Worst case scenario there should be a new init-param. Rémy
Re: Wrong content-type for CSS files since 8.5.37 / 9.0.14
On December 26, 2018 9:49:00 PM UTC, "i...@flyingfischer.ch" wrote: >Tomcat versions 8.5.37 and 9.0.14 seem to serve CSS files embedded in a >webapp as > >content-type: text/html;charset=UTF-8 > >instead of > >content-type: text/css;charset=UTF-8 > >This causes the browser (FF) not to interpret the CSS. > >I suspect the listed change in changelog of 8.5.36: "The default >Servlet >should not override a previously set content-type. (remm)" Sounds likely. Whatever part of the app is setting the incorrect content type (probably a filter) needs to be fixed. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: log4j app logging
On Wed, Dec 19, 2018 at 06:52:20PM +, Lemke, Michael ST/HZA-ZIC2 wrote: > On December 19, 2018 6:54 PM Lemke, Michael wrote: > >On December 18, 2018 8:52 PM Christopher Schultz wrote: > >>On 12/18/18 12:42, Lemke, Michael ST/HZA-ZIC2 wrote: > >>> I have an old webapp that uses log4j 1.2 and which I am trying to > >>> deploy on tomcat. For the heck of it I can't get tomcat to use the > >>> log4.properties file. What am I doing wrong? > >> > >> > >>How are you initializing log4j? > > > >Good question. I just dug a little and have to say I don't know. It > >is a myfaces 1.1 application and I just realized jsf has logging built > >in somehow. I can't find any explicit call to Logger.getLogger in the > >code. > > > >I guess I have a terrible mess of all sorts of loggers in my libraries. I am > >not good at all the different Java loggers. The log4j.properties I want > >to use is for log4j-1.2.27 so not quite bleeding edge ??. Then there are > >other libs that pull in slf4j-api-1.7.25.jar, there is a > >jcl-over-slf4j-1.7.25.jar, > >logback-classic-1.2.3.jar, logback-core-1.2.3.jar. > > > >Well, I do get quite lot of logging from the app in the tomcat logfiles, so > >something is working. But I don't know how to configure it. > > > >This used to work when I ran it on resin but I also changed quite a bit on > >the code when I switched to tomcat. I'll try without all the new stuff. > > And this was it. The old version without the stuff that pulls in all the other > log libraries it works. So tomcat is out of the loop. Sorry for the noise. > (But if someone has a hint on my mess I wouldn't mind.) If this happens to be a project built with Maven then 'mvn dependency:tree' should tell you which artifacts are pulling in SLF4J. You may need to run this more than once as you comb out transitive dependencies one by one. But it's possible to use multiple logging frameworks in one webapp. if you include/exclude the right artifacts. See https://www.slf4j.org/legacy.html if you need to do this with SLF4J and Log4J v1. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu signature.asc Description: PGP signature
Re: Tomcat 9.0.14 startup fails
https://stackoverflow.com/questions/28776520/systemd-service-for-jar-file-gets-operation-timed-out-error-after-few-minues-o this issue is familiar your‘s，hope this answe wil help you！ Steve Demy 于2018年12月27日周四 下午12:20写道： > Tomcat 9.0.14 startup fails, or at least is not recognized as complete by > Ubuntu’s systemd which times out: > > Dec 25 05:19:09 vps169399 catalina.sh[9716]: 25-Dec-2018 05:19:09.586 INFO > [main] org.apache.catalina.startup.Catalina.start Server startup in [1,868] > milliseconds > Dec 25 05:20:34 vps169399 systemd[1]: tomcat.service: Start operation > timed out. Terminating. > > A stop operation then fails (port 8005 held by the hung start operation?) > and tomcat is killed by the OS. > > Systemd then restarts Tomcat 10 seconds later resulting in a start/stop > loop. After a system reboot, one start operation will proceed normally, > but any restart results in the start/stop loop. There are no webapps > involved except the tomcat packed ones. > > Tomcat 9.0.13 works perfectly with identical installation and > configuration. What is systemd is expecting that it is not getting from > 9.0.14? Any clue will be much appreciated. > > The systemd script and full startup log are enclosed below, which contains > details of the environment. > > [Unit] > Description=Apache Tomcat Web Application Container > After=network.target > > [Service] > Type=forking > > Environment=JAVA_HOME=/usr/lib/jvm/jdk-11.0.1 > Environment=CATALINA_PID=/opt/tomcat/temp/tomcat.pid > Environment=CATALINA_HOME=/opt/tomcat > Environment=CATALINA_BASE=/opt/tomcat > Environment='JAVA_OPTS=-Djava.awt.headless=true > -Djava.security.egd=file:/dev/./urandom' > Environment=LD_LIBRARY_PATH=/opt/tomcat/lib > Environment='CATALINA_OPTS=-Xms1024m -Xmx1024m' > > ExecStart=/opt/tomcat/bin/startup.sh > ExecStop=/opt/tomcat/bin/shutdown.sh > > User=tomcatuser > Group=tomcatgroup > UMask=0007 > RestartSec=10 > Restart=always > > [Install] > WantedBy=multi-user.target > > > Complete startup log: > > -- Unit tomcat.service has begun starting up. > Dec 25 05:19:04 vps169399 catalina.sh[9716]: NOTE: Picked up > JDK_JAVA_OPTIONS: --add-opens=java.base/java.lang=ALL-UNNAMED > --add-opens=java.base/java.io=ALL-UNNAMED > --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED > Dec 25 05:19:06 vps169399 catalina.sh[9716]: 25-Dec-2018 05:19:06.362 INFO > [main] org.apache.catalina.startup.VersionLoggerListener.log Server version > name: Apache Tomcat/9.0.14 > Dec 25 05:19:06 vps169399 catalina.sh[9716]: 25-Dec-2018 05:19:06.376 INFO > [main] org.apache.catalina.startup.VersionLoggerListener.log Server built: > Dec 6 2018 21:13:53 UTC > Dec 25 05:19:06 vps169399 catalina.sh[9716]: 25-Dec-2018 05:19:06.380 INFO > [main] org.apache.catalina.startup.VersionLoggerListener.log Server version > number: 9.0.14.0 > Dec 25 05:19:06 vps169399 catalina.sh[9716]: 25-Dec-2018 05:19:06.381 INFO > [main] org.apache.catalina.startup.VersionLoggerListener.log OS Name: > Linux > Dec 25 05:19:06 vps169399 catalina.sh[9716]: 25-Dec-2018 05:19:06.382 INFO > [main] org.apache.catalina.startup.VersionLoggerListener.log OS Version: > 4.15.0-43-generic > Dec 25 05:19:06 vps169399 catalina.sh[9716]: 25-Dec-2018 05:19:06.383 INFO > [main] org.apache.catalina.startup.VersionLoggerListener.log Architecture: > amd64 > Dec 25 05:19:06 vps169399 catalina.sh[9716]: 25-Dec-2018 05:19:06.383 INFO > [main] org.apache.catalina.startup.VersionLoggerListener.log Java Home: > /usr/lib/jvm/jdk-11.0.1 > Dec 25 05:19:06 vps169399 catalina.sh[9716]: 25-Dec-2018 05:19:06.384 INFO > [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Version: > 11.0.1+13 > Dec 25 05:19:06 vps169399 catalina.sh[9716]: 25-Dec-2018 05:19:06.384 INFO > [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor: > Oracle Corporation > Dec 25 05:19:06 vps169399 catalina.sh[9716]: 25-Dec-2018 05:19:06.386 INFO > [main] org.apache.catalina.startup.VersionLoggerListener.log > CATALINA_BASE: /opt/tomcat > Dec 25 05:19:06 vps169399 catalina.sh[9716]: 25-Dec-2018 05:19:06.386 INFO > [main] org.apache.catalina.startup.VersionLoggerListener.log > CATALINA_HOME: /opt/tomcat > Dec 25 05:19:06 vps169399 catalina.sh[9716]: 25-Dec-2018 05:19:06.387 INFO > [main] org.apache.catalina.startup.VersionLoggerListener.log Command line > argument: --add-opens=java.base/java.lang=ALL-UNNAMED > Dec 25 05:19:06 vps169399 catalina.sh[9716]: 25-Dec-2018 05:19:06.388 INFO > [main] org.apache.catalina.startup.VersionLoggerListener.log Command line > argument: --add-opens=java.base/java.io=ALL-UNNAMED > Dec 25 05:19:06 vps169399 catalina.sh[9716]: 25-Dec-2018 05:19:06.390 INFO > [main] org.apache.catalina.startup.VersionLoggerListener.log Command line > argument: --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED > Dec 25 05:19:06 vps169399 catalina.sh[9716]: 25-Dec-2018 05:19:06.392 INFO > [main] org.apache.catalina.startup.VersionLogge
