Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 325468

Summary:

Jetty deploys new version of WAR incorrectly

Product:

[RT] Jetty

Reporter:

Mark Phippard <markphip>

Component:

server

Assignee:

Greg Wilkins <gregw>

Status:

RESOLVED FIXED

QA Contact:

Severity:

blocker

Priority:

CC:

jesse.mcconnell, jetty-inbox

Version:

7.0.2

Target Milestone:

7.1.x

Hardware:

OS:

All

Whiteboard:

Attachments:

Description	Flags
Small change to webapp unpack logic to fully remove old folder	jesse.mcconnell: iplog+

Description Mark Phippard

2010-09-16 09:55:15 EDT

I have an application deployed in production using Jetty 7.0.2. This is an open-source application and there over 10k deployments we know of. We have I think a fairly standard Jetty deployment. We deploy our WAR file to the webapp folder. We have an XML file in the contexts folder and we have a work folder where Jetty expands the WAR at runtime.

We have an update mechanism for this application that will put a new copy of the WAR file into the webapps folder when we have a new release. The name of the WAR file does not change and we stop and restart the Jetty application server as part of this process. This has worked pretty well so far, we have delivered 5 releases successfully.

In our next release we are upgrading some of our dependencies to newer versions (Grails, Hibernate etc.). In testing, we have discovered that our deployment mechanism does not work properly and the app fails to restart.

We have traced the problem to the way that Jetty deploy the WAR file. It looks like it simply unpacks the WAR file on top of the old temp directory in the work folder. We think it should delete the existing temp directory and create a new one.

The problem is that our application lib folder now has multiple copies of the same JAR's For example:

grails-bootstrap-1.2.1.jar
grails-bootstrap-1.3.4.jar
grails-core-1.2.1.jar
grails-core-1.3.4.jar
grails-crud-1.2.1.jar
grails-crud-1.3.4.jar
grails-docs-1.2.1.jar
grails-gorm-1.2.1.jar
grails-gorm-1.3.4.jar
grails-resources-1.2.1.jar
grails-resources-1.3.4.jar
grails-spring-1.2.1.jar
grails-spring-1.3.4.jar
grails-web-1.2.1.jar
grails-web-1.3.4.jar

This causes the application to not work when it restarts. We are really stuck here. The only thing we can think of is to try to devise our own hack to delete the temp folders ourselves. This is not going to be easy and it seems like Jetty ought to behave differently. I am hoping there is just some option in our Jetty configuration XML files we can change to modify this behavior. We could then deploy that XML change with the WAR file and the restart would work.

Comment 1 Mark Phippard

2010-09-16 10:20:55 EDT

If you have any questions about the jetty.xml we are using, you can view it here:

https://ctf.open.collab.net/integration/viewvc/viewvc.cgi/trunk/console/svn-server/appserver/etc/jetty.xml?revision=1271&root=svnedge&system=exsy1005&view=markup

http://bit.ly/9nZkbI

Comment 2 Greg Wilkins

2010-09-16 10:27:44 EDT

Ah! Strange that we've never had this reported before... seams so obvious now that you mention it!

We will get it fixed for the next release.

Comment 3 Geoffrey

2010-09-16 16:40:30 EDT

Created attachment 179072 [details]
Small change to webapp unpack logic to fully remove old folder

This patch fully clears the unpacked webapp location prior to extracting a newer version. This is particularly needed if the new WAR file has deletions (such as updated lib jars with new version names).

The existing logic uses File.delete() to remove the old exploded dir, but this will silently fail if the folder has any content. The patch instead uses org.eclipse.jetty.util.IO.delete(), which makes recursive deletes of all child elements.

Comment 4 Mark Phippard

2010-09-16 16:44:12 EDT

We applied this patch to our 7.0.2 version, rebuilt it and confirm that it resolves our problem.

Comment 5 Greg Wilkins

2010-09-16 18:32:34 EDT

thanks for the patch.

Applied in r2284