geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject Re: online and offline deployment
Date Tue, 09 Nov 2004 17:27:53 GMT
Aaron Mulder wrote:
> Jeremy,
> 	What is your feeling on the "package --install" command?  Because
> right now, that runs in offline mode, and assumes that it should install
> into a file-based local configuration store.  Which means it's subject to
> all the problems you've raised if the server is not using a file-based
> local configuration store, etc.

The original purpose of that (in the old offline deployer) was to 
install the generated configuration in the /deployer's/ config store to 
that it could be used to resolved dependencies for future deployments. 
It was the happy co-incidence (ok, a bootstrap hack) that the deployer 
and server were using the same store that allowed us to pre-load 
configurations into it.

> 	Of course we use this during server construction.  But it might be
> best to start the server immediately after bootstrapping the deployer, and
> do all the rest of the server construction tasks as online deployments.  
> (That would also have the pleasant side effect of making it all run
> faster, because you wouldn't be starting and stopping a kernel for every
> deployment.)  

I'm all for making it faster but I have reservations about starting the 
server during the build process as that will trigger a lot of 
initialization code (like creating a transaction log, a Derby database, 
etc.) We could nuke it after building the configs but that seems funky.

One thing that was talked about a while ago (off-list probably :-) ) was 
the concept of having a deployment server that could be used to perform 
deployments. It would basically be the deployment config running as a 
Daemon which a deployer could talk to; the server would do the 
deployment and return the configuration it built to the deployer. As the 
configurations were portable they could then be moved around to the 
servers where they were intended to run.

If we changed the bootstrap code to build such a deployment server, then 
it could used during the build process and we would not have to create 
new JVMs all the time.

It should be possible to boot such a server inside the Maven VM and talk 
to it directly. In fact, with a couple of minor tweaks that might even 
be possible with the current standalone deployment config.

> Then the bootstrapping would be the only operation that
> actually installed in offline mode, and we could remove the unsafe
> "--install" option from the package command -- or actually make the
> package command perform the installation in online mode, if we have a
> deployment module that knows how to deploy a "CAR" file.  Or better yet,
> have the package command run in reverse order -- first distribute the
> configuration into the running server, and then dump a CAR file from the
> configuration in the config store.

Aside from building the initial deployer (the hard coded Bootstrap 
class) I don't think we should do anything special to build the default 
server configuration. We should be able to do it the same way any other 
user would configure their own server.

The challenge facing us and any other user is the same - pre-loading a 
server's configuration store. The command line executable "CAR" can be 
built by the standalone deployer as can all of its configurations. The 
problem is how to get them into the new server's store(s).

As I've said before, we currently hack this by making the deployer and 
server use the same store but we really need to find a general solution.

I have a half-baked idea about a special type of bootstrap deployment 
where the deployer would interact with a fledging server to set up its 
stores and repositories and then install the appropriate jars and 
configurations. This would be driven by bootstrap plan (probably in XML) 
that told it what to do. I need to think a bit more and I'll send in a 
proposal to the list when its a little more done.

Hey, perhaps we could discuss this off-list at ApacheCon ;-)


View raw message