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