CODEWITHSUNDEEP
tomcat
JavaSheriff
JavaSheriff

Reputation: 7687

Apache-tomcat-8.5.29 overrides the content of the exploded folder?

I am doing an upgrade from older version of tomcat to 8.5.29
I have a tomcat server with WAR file and exploded folder

tomcat8/webapps/xerox.war and tomcat8/webapps/xerox

The exploded folder contains patches that doesn't exist in the WAR
I would like tomcat to use only the exploded folder and ignore the WAR file.

So in server.xml, on the Host section I set the unpackWARs to true, and autoDeploy to false,
It seems like its not working ok, and stuff in the exploded folder gets overridden / deleted after restart.

  <Host name="localhost"  appBase="webapps"
        unpackWARs="true" autoDeploy="false">

What am I doing wrong?

Upvotes: 1

Views: 740

Answers (2)

JavaSheriff
JavaSheriff

Reputation: 7687

Using the first answer about war-tracker that I didn't know exist...

I ended up finding this method, it seems like its working fine

touch ./tomcat8_NEW/webapps/xerox/META-INF/war-tracker -r ./tomcat001_old/webapps/xerox.war

This creates a new war-tracker file in the META-INF directory and clone the WAR timestamp
So tomcat thinks that there are no changes to the WAR and doesn't do anything to the exploded dir.

Thank you @Piotr P. Karwasz for your answer, I will accept it.

Upvotes: 0

Piotr P. Karwasz
Piotr P. Karwasz

Reputation: 16185

Tomcat creates a META-INF/war-tracker empty file in the unpacked WAR folder (tomcat8/webapps/xerox). If the modification time in milliseconds (cf. stat, since I assume you are under *nix) is exactly the same for both he WAR file and the tracker the directory is left alone. Otherwise Tomcat deletes the directory and unpacks the WAR file again.

The autoDeploy="false" setting does not influence this behavior, unless you also set deployOnStartup="false", in which case both the WAR file and the expanded directory will be ignored by Tomcat. This is not what you want.

You have two solutions:

  • stop Tomcat and delete the WAR file,
  • keep them both, but check if something (e.g. a backup system) is not modifying the timestamps of the WAR file and tracker file.

Upvotes: 1

Related Questions