Arkiv för 'Tomcat'
Stoppa Tomcat ”med våld”
Postat av Ulf den 18 januari, 2010, i Java, Linux, Tomcat, Webbutveckling.
Ibland hänger sig Tomcat, och hur man än försöker går den inte att stanna. Med kommandot
ps -ef | grep "tomcat"
kan man se om det finns någon Tomcat-process kvar efter det att man försökt stoppa servern. Skulle så vara fallet, kan man med kommandot
kill -9 tomcat
stoppa Tomcat med våld.
Dynamiskt deployment med Ant på Tomcat
Postat av Ulf den 21 april, 2009, i Java, Tomcat, Webbutveckling.
Det finns en mycket smidig möjlighet att via Ant installera och ladda om Java-webbapplikationer på Tomcat. Man definerar helt enkelt Ant-targets som installerar webbaplikationen via Tomcats manager.
Konfigurera Ant
För att detta skall fungera måste man
1. först kopiera filen catalina-ant.jar från Tomcats lib-katalog till Ants lib-katalog
2. definera en manager-användare Ant kan använda sig av i Tomcats användarfil /conf/tomcat-users.xml, till exempel så här:
<?xml version='1.0' encoding='utf-8'?> <tomcat-users> <role rolename="manager"/> <user username="ant" password="ant_password" roles="manager"/> </tomcat-users>
3. lägga till nya targets i Ants build.xml, till exempel så här:
<!-- Konfigurera build-katalogen -->
<property name="build" value="${build.dir}"/>
<!-- Konfigurera sökvägen för applikationen (context path) -->
<property name="path" value="/myContextPath"/>
<!-- Konfigurera access till Tomcats manager -->
<property name="url" value="http://localhost:8080/manager"/>
<property name="username" value="ant"/>
<property name="password" value="ant_password"/>
<!-- Konfigurera de tasks som man vill köra mot managern -->
<taskdef name="deploy" classname="org.apache.catalina.ant.DeployTask"/>
<taskdef name="reload" classname="org.apache.catalina.ant.ReloadTask"/>
<taskdef name="undeploy" classname="org.apache.catalina.ant.UndeployTask"/>
<taskdef name="remove" classname="org.apache.catalina.ant.RemoveTask"/>
<!-- Konfigurera targets. -->
<!-- Detta exempel förusätter att det finns ett target "war" som bygger den war-fil som skall deployas-->
<target name="deploy" description="Install web application"
depends="war">
<deploy url="${url}" username="${username}" password="${password}"
path="${path}" war="file:${build}${war}"/>
</target>
<target name="reload" description="Reload web application"
depends="war">
<reload url="${url}" username="${username}" password="${password}"
path="${path}"/>
</target>
<target name="undeploy" description="Remove web application">
<undeploy url="${url}" username="${username}" password="${password}"
path="${path}"/>
</target>
<target name="remove" description="Remove web application">
<undeploy url="${url}" username="${username}" password="${password}"
path="${path}"/>
</target>
Därefter skall det gå att via
ant deploy
bygga applikationen och installera den på Tomcat, utan att behöva starta om servern.
Problem 1: Låsta JARs
Ett problem jag stötte på var att vid ett
ant undeploy
blev en del jar-filer hängande kvar i applikationens lib-katalog. Tomcat låser dessa när applikationen exekveras, och tas därför inte bort vid ett undeploy. ant deploy misslyckas med följande felmeddelande:
[deploy] FAIL - Application already exists at path /myContextPath
Man måste därför tala om för Tomcat att inga filer får låsas. Detta görs genom att man i katalogen META-INF (ligger i samma katalog som WEB-INF) lägger till en fil context.xml med följande innehåll:
<Context antiJARLocking="true" antiResourceLocking="true"> </Context>
En nackdel med det här är att Tomcat sedan inte märker när en fil uppdateras, och laddar den dynamsikt på nytt. Gör inget i en produktionsomgivning, men stör under utvecklingen.
Problem 2: ClassCastException
Ett annat problem jag stötte på vid
ant reload
var att applikationen inte kunde startas på grund av en ClassCastException:
Caused by: java.lang.ClassCastException: org.apache.xerces.parsers.XML11Configuration cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration
Jag hade Xerces som bibliotek i min applikation. Helt i onödan, visade det sig, jag kunde ta bort det utan att det uppstod några kompilerings- eller runtime-fel. Tydligen krockar Xerces med Tomcats egen XML-parser. Lite lustigt, då jag i Tomcats bibliotek inte kunde hitta någon Xerces. Men efter det att jag tagit bort Xerces och gjort en ant undeploy och en ant deploy funkade allt som det skulle.
