geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: online and offline deployment
Date Tue, 09 Nov 2004 18:27:11 GMT

On Nov 9, 2004, at 9:27 AM, Jeremy Boynes wrote:

> 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.

I don't think this will work until all the deployment code is in 
different modules from the runtime code.  That's why I've been trying 
so hard to get it separated.

david jencks

>> 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 ;-)
> --
> Jeremy

View raw message