geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: Review of refactored deployment classes
Date Wed, 15 Oct 2003 17:04:48 GMT
	I have to agree with David.  Part of the "distribute" step will
involve ensuring that the package is runnable (validation, generating any
required code, etc.), and another part is generating a living MBean with
which the archive/application can be started, removed, etc.  I don't think
it's sufficient to simply place the file somewhere.  And I also agree with
David that the deployment scanner should feed into the deployment logic
and not vice versa.

Aaron

On Wed, 15 Oct 2003, David Jencks wrote:
> > This is an approach. What do you think of the following one:
> >
> > When a module is distributed, it is stored in a passive directory. 
> > When this module needs to be started, one adds to the deployment 
> > scanner its URL and the standard deployment process kicks off.
> >
> > To distribute a module in an auto-deploy folder will be a two step 
> > process: firstly upload it in a passive directory (one does not want a 
> > module being distributed to be retrieved by a scanner) and then move 
> > it to the auto-deploy folder. So, why not do it "in-place".
> >
> 
> I think relying on scanning and scanning-driven hot deployment for 
> anything is a big mistake.  I think that whatever the "official" 
> deployment method is, the scanner should simply be one input to it.  
> You should be able to have a "locked down" Geronimo instance with no 
> scanners.
> 
> When Geronimo can remember its state between shutdowns, I think it will 
> appear much less important to have a scanner.
k


Mime
View raw message