geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Boynes" <>
Subject RE: [Deployment] Directories
Date Fri, 03 Oct 2003 18:07:41 GMT
On the role of the deploy directory....

There is nothing special there. We have a DeploymentScanner MBean that
will scan a location and report back on the things that it finds; this
get passed to the planner to work out what to do with it. The deploy
directory is simply the default location for a scanner that is started
at boot.

Anything that is explicitly deploying an application should *NOT* do it
by copying stuff into the deploy directory. Instead it should pass a URL
to the DeploymentPlanner and let it figure out the details.

For JSR-88, there could be a couple of approaches to distribution. For
* something copies the archive to a shared location and passes that URL
  the target deployers. The shared location could be a file: URL for a
NFS partition,
  a http: URL for a WebDAV server, a jdbc: URL for a LOB in a RDBMS, ...

* the archive is distributed local to all targets and then deployed used
a local
  file: URL. The distribution mechanism could be anything e.g. rsync,
  rcp, ftp, JGroups, ...

So basically, distribution is a different problem from deployment.

On the role of versioned applications, this needs to be carefully
thought out. There are some basic design issues, like at what point does
the transition happen e.g. on method call, HTTP request, HTTP Session
start, ... This determines how long the two versions co-exist.

I am not sure we've all thought this through yet :-)


> -----Original Message-----
> From: n. alex rupp [] 
> Sent: Friday, October 03, 2003 9:47 AM
> To:
> Subject: Re: [Deployment] Directories
> I'm not certain we're moving in the right direction with this, Aaron.
> <snip/>
> > 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.
> Two questions.
> 1.  Does the CMP engine already perform version handling for 
> the persistence
> layer?
> 2.  Is, therefore, this problem limited to the servlet layer in the
> application?
> If both of these are true, then I suggest we leave servlet 
> versioning to the
> servlet container and associated servlet framework providers.
> > 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?
> I'm not sure we should be copying and shuffling entire 
> archives around.  It
> seems like it would be very resource intensive and confusing 
> for the end
> user.  Is there another way we could be thinking about this other than
> directories in the file system?  I believe the deploy 
> directory is really
> just another part of the user interface and that the problems of
> classification and deployment should be separated from that 
> UI and handled
> under the covers by the server.
> --
> N. Alex Rupp

View raw message