geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: online and offline deployment
Date Tue, 09 Nov 2004 15:37:35 GMT
	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.

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

	I think someone raised some of these possibilities before, but I
don't remember who.


On Mon, 8 Nov 2004, Jeremy Boynes wrote:
> I argue that JSR-88 features such as start, stop, ... that are intended 
> for online use do not work in offline mode and trying to implement them 
> is resulting in an incomplete solution that will be problematic in all 
> but the degenerate case. The plan to hack start based on a specific 
> implementation of ConfigurationStore is indicative that there is 
> something fundamentally wrong here.
> Aaron tried to implement the feature as planned, ran into a problem, and 
> asked on the list if anyone minded if he hacked around it. I did, for 
> reasons that have been explained.
> Can you take another look at the mails again and see if you can come up 
> with a proposal that works? I would hate to waste another day writing a 
> another mail that you do not understand.
> And despite the on-list conversations that make it pretty clear I think 
> there are technical problems, to keep you happy here is a formal -1 veto 
> on any implementation intended for general use that couples the 
> standalone deployer to the implementation of the target server's config 
> store or which requires the deployer to boot the target server to do 
> offline deployment. I have already +1'd Aaron's existing changes.
> --
> Jeremy

View raw message