geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject [Deployment] Directories
Date Fri, 03 Oct 2003 13:10:21 GMT
	So we've got the one main deploy directory, where you can dump 
stuff that you want to deploy (apps, server modules, etc.).  The JSR-88 
separation of "distribute" and "deploy" raises some problems though.  When 
"distribute" is called for an application, the application needs to be 
sent out to the server(s) in question and validated and so on, but not 
actually deployed.  So we can't store a "distributed" application in the 
deploy dir -- if we did, it would be deployed!

	Another issue is that it's often convenient to unpack application 
modules (EARs, RARs, etc.) since it's less convenient to, for example, put 
a JAR in a JAR into a ClassLoader.  So we usually end up with some sort of 
temporary directory for unpacked applications.

	Next, if we want to support the best-case deployment behavior,
where old requests finish against the old code and new requests go against
the new code, we need to be able to maintain multiple versions of the same
application, at least temporarily.

	Finally, if a JSR-88 application is distributed and deployed 
(without ever going through the normal "deploy" directory routine), and 
the server is restarted, ideally we'd start that application too, even 
though it's not in the deploy dir.

	So all this leads me to the question of what directories do we set
up for deployments, and how do we populate them?

	I'm thinking that our authoritative location for deployable
applications should not be the same as the auto-deploy directory.  For
example, we create the dir "applications", and every time a new app is
placed in the normal "deploy"  dir, it gets copied to "applications" (with
a timestamp in the name or something) and unpacked if necessary, and then
deployed from there.  The JSR-88 logic can dump things directly into
"applications" when a "distribute" command is received.  When you update
the copy in the "deploy" dir, it creates a new entry in the "applications"
dir and kicks off a deployment against that, removing the old one once old
requests have finished or whatever.  If we have to, we can put a token
file in the unpacked directory under "applications" indicating the current
state (distributed, running, stopping, etc.).  When you restart the
server, we first process all the files in the "deploy" directory, and then
go on and process everything in the "applications" directory, so we catch
both the user-updated files and the previous JSR-88 deployments.

	How does that all sound?  Anyone have a better alternative?


View raw message