Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <4190FE19.1050602@gluecode.com>
References: <418DB7EE.3070408@apache.org>
 <Pine.LNX.4.58.0411070704300.8156@saturn.opentools.org>
 <72C6CADB-31D0-11D9-9A4F-000D93C5B79C@gluecode.com>
 <41901B3F.1040906@apache.org>
 <Pine.LNX.4.58.0411091026200.26039@saturn.opentools.org>
 <4190FE19.1050602@gluecode.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <F92BF7D7-327C-11D9-8F70-000D93361CAA@gluecode.com>
Content-Transfer-Encoding: 7bit
From: David Jencks <djencks@gluecode.com>
Subject: Re: online and offline deployment
Date: Tue, 9 Nov 2004 10:27:11 -0800
To: dev@geronimo.apache.org


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
>