geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Review of refactored deployment classes
Date Wed, 15 Oct 2003 16:44:29 GMT

On Wednesday, October 15, 2003, at 05:43 AM, gianny DAMOUR wrote:

<big snip>
>>    I'm not sure that this call should be in there:
>>      deploymentPlan.addTask(new
>>                               StartRecursiveMBeanInstance(server,
>> dmdMetaData));
>>   because if this is a hot-deployment this is fine, but if this is a
>>   JSR-88 distribute () then we don't want to automatically start
>>   anything. I believe that the deployment mechanism we have now
>>   should serve both hot-deploys and distribute()s, so it would be
>>   some other code in the deployment mechanism that would be
>>   responsible for working out if it is a hot deploy and ensuring
>>   startRecursive is called on the
>>   "geronimo.deployment:role=DeploymentUnit,..." mbean.
> 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 

When Geronimo can remember its state between shutdowns, I think it will 
appear much less important to have a scanner.

<another big snip>


* David Jencks
* Partner
* Core Developers Network

View raw message