geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject Re: Distribution and start/stop of clustered deployments
Date Tue, 20 Nov 2007 20:55:55 GMT

Gianny Damour wrote:
> On 17/11/2007, at 12:30 AM, Kevan Miller wrote:
>> On Nov 13, 2007, at 9:36 PM, Gianny Damour wrote:
>>> Hi Joe,
>>> After some investigations, here is my understanding of problem 1: 
>>> there are two deployments because by default, i.e. when no target is 
>>> specified, the distribute command executes against all the 
>>> configuration stores defined by a Geronimo instance. Note that this 
>>> default behavior is also applied by other deployment components, such 
>>> as the hot directory scanner or the installation portlet. To some 
>>> extent, I believe this default behavior should be changed to deploy 
>>> to only one configuration store. Indeed, I am not convinced that 
>>> users distributing applications would expect their applications to be 
>>> deployed as many times as the number of configuration stores defined 
>>> by the targeted Geronimo server. Also, having the same configuration 
>>> multiple times in a Geronimo instance does not make a lot of sense.
>>> A potentially better default behavior would be: only distribute to 
>>> the first target returned by DeploymentManager.getTargets(). 
>>> Internally, our implementation of getTargets returns as the first 
>>> target the "default" configuration store.
>>> Problem 3) is caused by problem 1).
>>> What do you think?
>> Hi Gianny,
>> That seems like reasonable behavior.
>> I haven't looked closely at this, yet. I'm curious about how 
>> list-modules would work. I'm also wondering about plugin installation, 
>> console support, etc. Have they been updated appropriately to reflect 
>> your multiple config store scheme?
> Hi Joe,
> I created a JIRA to track this change of behavior and will soon commit 
> the change.

Hi Gianny,

Sorry for the delay ... somehow I missed this response.  Yes, I think 
that default configuration store approach makes sense.  Thanks for 
opening the JIRA.  I presume that a deploy would have to specify the 
configuration store if it were other than the default, correct?

> Regarding the list-modules command, it lists all the configurations per 
> target, i.e. configuration store.

As Kevan also pointed out, I think that we need to consider the multiple 
configuration stores in the console when more than one is present for 
display and deploy (including plugins) as well as the CLI.  With your 
changes proposed above I would presume that they would always work with 
the default configuration store (the first one returned) until they can 
be updated to support multiple.

> Thanks,
> Gianny
>> --kevan

View raw message