geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Boynes" <>
Subject RE: [Deployment] IM #2 Summary for Directory Issue
Date Sat, 04 Oct 2003 07:50:19 GMT
> From: Aaron Mulder [] 
> Sent: Friday, October 03, 2003 3:38 PM
> 1) There will be some way of saving the current MBean state 
> of the server and reloading it later.  That way when you 
> start the server, instead of reprocessing all the config 
> files, it will just "deserialize" the MBeans into their 
> previous state.  Then the deployment scanner will update that 
> state according to the current deploy directory (redeploying 
> a service if the config file changed, for example).  
> (Apparently this saving and loading is a work in progress at 
> the moment.)
> 2) There will be a "service controller" that manages the 
> JSR-77 state of various objects in the server.  I need to get 
> more information about this from Dain.  But the relevant part 
> is that based on the above, all the applications that were 
> previously deployed have MBeans, and those MBeans would 
> brought back in the "stopped" state when the server is started.  
> Then with the service controller in place, the service 
> controller can go try to start the ones that were formerly 
> running.  Thus it is the service controller (or if not, then 
> the MBeans), not the individual app DDs, which remember what 
> state the different components are in.
> 2a) A possible corollary of "2" is that if the service 
> controller knows what should be running or not at any given 
> time, that solves the problem of what to do when something in 
> the "deploy" directory is stopped.  The service controller 
> knows it was stopped, so we won't try to redeploy it immediately.
We should not confuse the different states here :-)

Firstly, there is configuration state - the values of MBean attributes
that can be persisted.

Secondly, there is operational state - the started/stopped/failed state
as define in JSR77. This is a transient attribute of the MBean
defaulting to stopped, so after a restore the MBean is initialized but
not started. One role of the service controller is to ensure all MBeans
get started in an order that satisfies their dependencies.

So the server startup is basically two phase:
1) "Cold start" where the MBeans are recreated from persistent
    store. When this has completed, all MBeans are present and
    in the JSR77 STOPPED state.

2) "Warm start" where the service controller starts each MBean 
    in the correct order.

The service controller persists the JSR77 state of each MBean and
listens to JSR77 state change events to ensure its persistent version
matches the running state of the server.

> 3) Jeremy feels strongly that if you deploy an app via 
> JSR-88, we should just save it in a "working" directory and 
> unpack it there, and not mix and match JSR-88 deployment 
> actions with "deploy directory" deployment actions.  On the 
> whole, I think we should focus on the larger differences 
> between this proposal and the last, and we can figure out 
> whether to save 
> downloads to the "working" directory or the "deploy" directory later.

The key thing there is nothing magic about the "deploy" directory. It is
simply a URL monitored by a DeploymentScanner to support the
"drop-the-archive-in-the-directory" style of deployment used today. The
scanner watches that directory and supplies a list of archive URLs to
the DeploymentPlanner which orchestrates their deployment.

The actual deployment process may require that an archive gets copied
locally and/or unpacked - for example, a WAR located at an http: URL
will need to be expanded to local files before TC/Jetty can use it. We
will need a separate "working" directory so hold these copies, but it
does not matter if the content was created from a source URL supplied by
the user or from a URL found by a DeploymentScanner.

The reasons that I don't think things should be stored in the "deploy"
directory are:
1) Its role as input to the scanner means that access to it is
   I would not anticipate having write access to it - e.g. if it is
   located on a WebDAV server, the ability to write may only be
   exposed to local users and not the server (which is the WebDAV
   Or, the user the server is running as just doesn't have permission to
   write to the directory.

2) The confusion between deployment using an API (via 88) and by
   dropping a file in a directory.


View raw message