You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Aaron Mulder <am...@alumni.princeton.edu> on 2003/10/03 15:10:21 UTC
[Deployment] Directories
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?
Aaron
Re: [Deployment] Versioning
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Fri, 3 Oct 2003, n. alex rupp wrote:
> My point here is that versioning issues should be resolved in the EJB and
> Servlet containers respectively, not by the application loader. I remember
> discussions specifically regarding the above example from several weeks ago
> occurring between dain and jeremy.
That's certainly a possibility. I thought the deployer would need
to be involved because I don't think you'd actually want to remove the old
files before that version of that app is fully disposed of. The
straightforward approach of just overwriting an old EAR with a new one
might inadvertently defeat some process where we phase in the new app and
phase out the old app. Perhaps it would be best to put some digits or a
timestamp as part of the file name of any application we distribute. For
instance, if the user provides a new version of "foo.ear" we save it as
"foo.ear.123" or something. Then the EJB/Web/Connector containers could
acess both the new content (foo.ear.123) and the old content (foo.ear.122)
until they're finished, at which time perhaps there could be a callback or
something to make sure the old version is deleted.
On Fri, 3 Oct 2003, n. alex rupp wrote:
> We should fork this thread and attend to the versioning issue at a more
> relaxed pace after we've all had some time to mull over it.
Okay, well, we can drop it for now, I don't feel all that
strongly.
Aaron
Re: [Deployment] Directories
Posted by "n. alex rupp" <ru...@umn.edu>.
> On Fri, 3 Oct 2003, n. alex rupp wrote:
> > I'm not certain we're moving in the right direction with this, Aaron.
>
> Well, that's why I asked!
=) Ahhh. The sweet smell of honest disagreements.
> > Two questions.
> > 1. Does the CMP engine already perform version handling for the
persistence
> > layer?
>
> I'm not sure what you mean. If the logic in one of your session
> beans changes, and you redeply the app, but at the moment you deploy it
> there's a request in process, what happens? I'm speculating that it would
> be best if the in-process request was fully resolved against the old
> session bean (possibly including calls out to other old session or entity
> beans), while new requests would resolve against the new version of the
> session bean (etc.). So I'm not sure how CMP versioning would help.
>
> (BTW, we don't have to resolve this now; we can just barf any
> in-process requests, but I thought it would be best to at least consider
> the issue up front.)
My point here is that versioning issues should be resolved in the EJB and
Servlet containers respectively, not by the application loader. I remember
discussions specifically regarding the above example from several weeks ago
occurring between dain and jeremy.
> > 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.
>
> I don't think so, based on the session bean example above.
>
> > 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.
>
> Okay... but when an application is deployed through JSR-88, I
> need somewhere to put it (most likely not in the deploy directory). I'd
> like to agree on where that should be.
Agreed : )
--
N. Alex Rupp (n_alex_rupp@users.sf.net)
Re: [Deployment] Directories
Posted by Siva <si...@sivasundaram.com>.
----- Original Message -----
From: "Aaron Mulder" <am...@alumni.princeton.edu>
To: <ge...@incubator.apache.org>
Sent: Saturday, October 04, 2003 12:15 AM
Subject: Re: [Deployment] Directories
> Okay... but when an application is deployed through JSR-88, I
> need somewhere to put it (most likely not in the deploy directory). I'd
> like to agree on where that should be.
>
How about defining a separate "Staging" directory which can be used
as a temporary placeholder for the jars?
Re: [Deployment] Directories
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Fri, 3 Oct 2003, n. alex rupp wrote:
> I'm not certain we're moving in the right direction with this, Aaron.
Well, that's why I asked!
> > 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?
I'm not sure what you mean. If the logic in one of your session
beans changes, and you redeply the app, but at the moment you deploy it
there's a request in process, what happens? I'm speculating that it would
be best if the in-process request was fully resolved against the old
session bean (possibly including calls out to other old session or entity
beans), while new requests would resolve against the new version of the
session bean (etc.). So I'm not sure how CMP versioning would help.
(BTW, we don't have to resolve this now; we can just barf any
in-process requests, but I thought it would be best to at least consider
the issue up front.)
> 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.
I don't think so, based on the session bean example above.
> 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.
Okay... but when an application is deployed through JSR-88, I
need somewhere to put it (most likely not in the deploy directory). I'd
like to agree on where that should be.
More coming in response to Jeremy's message...
Aaron
Re: [Deployment] IM Summary for Directory Issue
Posted by Greg Wilkins <gr...@mortbay.com>.
Aaron Mulder wrote:
> 2) For each application module in the deploy directory, we will save the
> Geronimo-specific DD outside the module, with a name based on the module
> name ("foo.war" gets the DD "geronimo-deployment-foo.war.xml" or something
> along those lines).
> 3) We will add tags to the DD to hold the deployment state of the module.
> When the module is distributed, started, stopped, etc. we will update the
> DD accordingly.
While I like the idea of a flat file descriptors that describe the current
requested state of the system deployment.
HOWEVER!
I really don't like this trend we are developing for copy and modify of
data like deployment descriptors!
Why not simply have a deployment state descriptor for all geronimo services
that is stored in parallel directories to the deploy directories (what
ever they may end up being).
The deployment state descriptor would be common to all services and capture
all the jsr77/jsr88 stuff that it needs to.
I see no value in merging the deployment state with the deployment descriptors
(and I see little value in merging the geronimo deployment descriptor with the
standard deployment descriptor). We are going to end up with so many copies of
the standard descriptors - all of which persist of a server restart, that it is
going to be very very confusing.
cheers
RE: [Deployment] IM Summary for Directory Issue
Posted by Jeremy Boynes <je...@coredevelopers.net>.
I think this thread has been superceded, but comments inline...
> -----Original Message-----
> From: Aaron Mulder [mailto:ammulder@alumni.princeton.edu]
> Sent: Friday, October 03, 2003 2:32 PM
> To: geronimo-dev@incubator.apache.org
> Subject: [Deployment] IM Summary for Directory Issue
>
>
> Alex and I talked a bit more by IM, and this is what we came up
> with. Please feel free to send any comments.
>
> 1) We will save all distributed files to one directory, and
> we will set
> that to be the same as the "deploy" directory by default (keeping all
> deployments in the same location, whether by user-copied files or by
> JSR-88).
I think this is confusing and may not even be possible (e.g. the server
may not have permission to write to the "deploy" directory).
>
> 2) For each application module in the deploy directory, we
> will save the Geronimo-specific DD outside the module, with a
> name based on the module name ("foo.war" gets the DD
> "geronimo-deployment-foo.war.xml" or something along those lines).
>
> 3) We will add tags to the DD to hold the deployment state of
> the module.
> When the module is distributed, started, stopped, etc. we
> will update the
> DD accordingly.
>
Storing this state is the responsibility of the service controller. We
do not need to copy the entire DD just to record the state of the MBean.
Indeed, the state of the MBeans involved is likely to be a superset of
the information in the DD.
> 4) When the server is started, it will deploy or not
> according to the tags in the DDs. If there is no state tag
> in the DD, we will assume that
> this is a new module to deploy and we will deploy it (and
> write in the
> state tag).
>
> 5) If no geronimo-specific DD is present, we will write one
> out to track
> the deployment state, and attempt to use intelligent defaults
> for the rest
> of the settings.
>
> This works fairly well for JSR-88, where the DD is
> maintained outside of the archive and sent to the server
> separately, and it shouldn't be too hard to implement for the
> directory scanning deployer (either the user copies the DD
> along with the archive, or we extract the Geronimo DD from a
> default location in the archive).
>
The geronimo-specific DD is one representation of the vendor-specific
configuration of the archive; there may be others (e.g. some entry in a
config management system). Defining this configuration is the first step
in the deployment process; distribution and start are separate steps and
I don't think we should mix the information they use.
--
Jeremy
[Deployment] IM Summary for Directory Issue
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
Alex and I talked a bit more by IM, and this is what we came up
with. Please feel free to send any comments.
1) We will save all distributed files to one directory, and we will set
that to be the same as the "deploy" directory by default (keeping all
deployments in the same location, whether by user-copied files or by
JSR-88).
2) For each application module in the deploy directory, we will save the
Geronimo-specific DD outside the module, with a name based on the module
name ("foo.war" gets the DD "geronimo-deployment-foo.war.xml" or something
along those lines).
3) We will add tags to the DD to hold the deployment state of the module.
When the module is distributed, started, stopped, etc. we will update the
DD accordingly.
4) When the server is started, it will deploy or not according to the
tags in the DDs. If there is no state tag in the DD, we will assume that
this is a new module to deploy and we will deploy it (and write in the
state tag).
5) If no geronimo-specific DD is present, we will write one out to track
the deployment state, and attempt to use intelligent defaults for the rest
of the settings.
This works fairly well for JSR-88, where the DD is maintained
outside of the archive and sent to the server separately, and it shouldn't
be too hard to implement for the directory scanning deployer (either the
user copies the DD along with the archive, or we extract the Geronimo DD
from a default location in the archive).
Aaron
Re: [Deployment] Directories
Posted by "n. alex rupp" <ru...@umn.edu>.
It's like . . . we're not communicating =)
> On Fri, 3 Oct 2003, Aaron Mulder opined . . .
> > ...
> > 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.
> > ...
> > 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 :-)
>
> Yes, well, that's why we're thinking it through now! :) Again, I
> don't think we have to solve the versioning issue today, but I thought it
> was worth including in the discussion.
Jesus God Man! (cops an imitation Hunter S. Thompson voice) Don't shout!
The wild dogs will hear. . . .
http://www.thedenverchannel.com/news/2505812/detail.html
=)
We should fork this thread and attend to the versioning issue at a more
relaxed pace after we've all had some time to mull over it.
> Another aspect of this issue is server startup. For most aspects
> of the server, there is some configuration file or other that is read
> during startup. But that is not currently the case for applications.
Sure it is. There are the web.xml and application.xml files--deployment
descriptors. There's also a service descriptor.
> ...
> Also, if we have this "distributed" directory, is the user allowed to put
> stuff in there? I would like them not to. If they update something in
> there, we'd probably ignore it. But what if they take down the server,
> add a new EAR to the "distributed" directory, and then start up the server
> again?
Exactly my point from before. People will meddle if they are allowed to,
and I can't really fault them for that. We'd be doing them and ourselves a
favor to come up with a way to handle distributed application deployments
without creating a separate directory for them. There must be some way to
flag an archive through its config files or some such so that it loads into
the "stopped" state, or does not load until instructed.
> Should it be ignored, loaded but not started, or started?
It shouldn't be put there to begin with. =)
> My
> prefernce would be to try to make it clear that if a user wants to deploy
> by manipulating files, they should use the "deploy" dir, and if they want
> to deploy via JSR-88, they should expect the server to use the
> "distributed" dir under the covers.
Sorry, man. -1
I'm not convinced.
In my humble opinion,
--
N. Alex Rupp (the humble and opinionated)
RE: [Deployment] Directories
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On Fri, 3 Oct 2003, Jeremy Boynes wrote:
> ...
> 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.
> ...
> So basically, distribution is a different problem from deployment.
True... But I have to implement them both in order for you to be
able to deploy an app from a proper JSR-88 client (which can certainly be
run from a different machine). I guess then we should say that for
purposes of this discussion, I'm looking to resolve part of the
"distribution" problem: Assuming I get a EAR/WAR/etc. over the network
(don't care what protocol, let's just assume I have bytes ready to save to
disk somewhere), where do I put it? I will then cause it to be deployed
via a URL pointing to whereever I just put it.
(Below, I will assume we picked a directory to save distributed
apps to, known as the "distributed" dir.)
> 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 :-)
Yes, well, that's why we're thinking it through now! :) Again, I
don't think we have to solve the versioning issue today, but I thought it
was worth including in the discussion.
Another aspect of this issue is server startup. For most aspects
of the server, there is some configuration file or other that is read
during startup. But that is not currently the case for applications.
For applications, we simply deploy whatever is present in the "deploy"
directory. I think that breaks in the presence of applications
distributed and deployed via JSR-88, since according to your point above
(and I agree), those distributed applications won't appear in the "deploy"
directory. So do we just not start any of those when the server starts?
I don't like that, I'd rather have the server start any apps that used to
be running, and deploy MBeans for (but not start) other apps that were
present but not running. Does that mean we also scan the "distributed"
directory during startup? If so, how do we know which apps there were
running or not? Do we save a single config file in the "distributed"
directory with the state of all the distributed apps, or one flag file per
application, or what?
Also, if we have this "distributed" directory, is the user allowed to put
stuff in there? I would like them not to. If they update something in
there, we'd probably ignore it. But what if they take down the server,
add a new EAR to the "distributed" directory, and then start up the server
again? Should it be ignored, loaded but not started, or started? My
prefernce would be to try to make it clear that if a user wants to deploy
by manipulating files, they should use the "deploy" dir, and if they want
to deploy via JSR-88, they should expect the server to use the
"distributed" dir under the covers.
Aaron
RE: [Deployment] Directories
Posted by Jeremy Boynes <je...@coredevelopers.net>.
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
example:
* something copies the archive to a shared location and passes that URL
to
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,
bittorrent,
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 :-)
--
Jeremy
> -----Original Message-----
> From: n. alex rupp [mailto:rupp0035@umn.edu]
> Sent: Friday, October 03, 2003 9:47 AM
> To: geronimo-dev@incubator.apache.org
> 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
>
>
>
Re: [Deployment] Directories
Posted by "n. alex rupp" <ru...@umn.edu>.
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