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


Reply via email to