Bug 56248 - Automatic deployment with TCD deletes customized context.xml file
Automatic deployment with TCD deletes customized context.xml file
Status: RESOLVED FIXED
Product: Tomcat 7
Classification: Unclassified
Component: Manager
7.0.52
PC Linux
: P2 normal (vote)
: ---
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2014-03-12 13:39 UTC by Jesse Barnum
Modified: 2014-03-17 12:17 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Barnum 2014-03-12 13:39:00 UTC
I was very happy to see the changes to automatic deployment, and that customized context.xml files in conf/Catalina/localhost/<appname>.xml are preserved when a war file is replaced on the server.

However, when using the ant tasks that come with TCD (and I suspect when using the Tomcat manager, although I have not tested that), it appears that the webapp is deleted and then uploaded (as opposed to just being replaced), which is causing the customized context.xml file to be lost and replaced with a default version.

=== Reply from Mark Thomas ===

Hmm. It looks like the update command does an undeployment followed by a
deploy rather than a replacement of the WAR file and a redeploy. You
aren't going to be able to fix that without code changes to Tomcat.
Changing the behaviour seems reasonable here. I suggest you open a
bugzilla issue for this.
Comment 1 Mark Thomas 2014-03-13 15:30:55 UTC
This has been fixed in 8.0.x for 8.0.4 onwards and in 7.0.x for 5.0.53 onwards.
Comment 2 Jesse Barnum 2014-03-13 15:35:24 UTC
Wow, thank you!!!
Comment 3 Konstantin Kolinko 2014-03-15 21:41:06 UTC
Reviewing r1577199

Besides two small issues that I mentioned in "Re: r1577199" thread on dev@, and bug 56273, one more high-level one:

The logic in update=true case in
    protected synchronized void deploy
        (PrintWriter writer, ContextName cn,
         String tag, boolean update, HttpServletRequest request,
         StringManager smClient) {

is as follows:
1. mark webapp as serviced
2. delete old war
3. upload new war,
 that means to read the body of a PUT request and save it as file
4. trigger deployment, remove serviced mark

If step 3. fails due to aborted I/O, the old application will become undeployed, deleting its custom configuration if there is any.

It would be better to upload it to a temporary name and rename the file.
A temporary name can be created with java.io.File.createTempFile(,,dir).
Comment 4 Mark Thomas 2014-03-17 12:17:27 UTC
I've fixed all of these issues for 8.0.x (8.0.4 onwards) and 7.0.x (7.0.53 onwards)