Re: list-targets command (proof of concept)
Thanks for the pointers Aaron,
Here's a proof-of-concept that allows Geronimo to run with two
LocalConfigStores and respects the target that you provide on the
deployer command line. It's only a proof-of-concept because it
doesn't address a few important issues:
o I didn't fix AppClientModuleBuilder, only allow it to run with two
config stores
o I don't think that the way the deployer chooses the default target
is ggod; it seems to be unpredicatble. It might be better to have an
explicit deploy to the default target command that lets the server
choose which target to deploy to.
o From a user perspective we might want to make the target naming
simpler or allow the user to use nicknames.
I'm sure there are lots of other wanna-haves but this indicates that
we're not that far off from having the basic functionality. I've got
to work on some other stuff for the next couple of days, and you're
probably going to be busy getting 1.0 out the door, but it would be
great if we could revisit this at some point.
Thanks,
Toby
Index: modules/assembly/maven.xml
===
--- modules/assembly/maven.xml (revision 354583)
+++ modules/assembly/maven.xml (working copy)
@@ -340,6 +340,7 @@
ant:echoBootstrapping service deployer/ant:echo
ant:mkdir dir=${geronimo.assembly.dir}/bin/
ant:mkdir dir=${geronimo.assembly.dir}/config-store/
+ant:mkdir dir=${geronimo.assembly.dir}/config-store2/
define:taglib uri=geronimo:bootstrap
define:jellybean
Index: modules/assembly/src/plan/system-plan.xml
===
--- modules/assembly/src/plan/system-plan.xml (revision 354583)
+++ modules/assembly/src/plan/system-plan.xml (working copy)
@@ -65,6 +65,12 @@
nameServerInfo/name
/reference
/gbean
+gbean name=Local2
class=org.apache.geronimo.system.configuration.LocalConfigStore
+attribute name=rootconfig-store2/attribute
+reference name=ServerInfo
+nameServerInfo/name
+/reference
+/gbean
!-- Repository --
gbean name=Repository
class=org.apache.geronimo.system.repository.FileSystemRepository
Index: modules/deployment/src/java/org/apache/geronimo/deployment/Deployer.java
===
--- modules/deployment/src/java/org/apache/geronimo/deployment/Deployer.java
(revision 354583)
+++ modules/deployment/src/java/org/apache/geronimo/deployment/Deployer.java
(working copy)
@@ -58,16 +58,55 @@
public class Deployer {
private static final Log log = LogFactory.getLog(Deployer.class);
private final Collection builders;
-private final ConfigurationStore store;
+private final Collection stores;
+private final ConfigurationStore defaultStore;
private final Kernel kernel;
-public Deployer(Collection builders, ConfigurationStore store, Kernel
kernel) {
+public Deployer(Collection builders, Collection stores, Kernel kernel) {
this.builders = builders;
-this.store = store;
+this.stores = stores;
+if (null != stores stores.size() 0) {
+this.defaultStore = (ConfigurationStore)stores.iterator().next();
+} else {
+this.defaultStore = null;
+}
this.kernel = kernel;
}
+
public List deploy(File moduleFile, File planFile) throws
DeploymentException {
+return deploy(planFile, moduleFile, null, true, null, null, null,
null, defaultStore);
+}
+
+
+/**
+ * Deploy the specified module/plan to the
+ * codeConfigurationStore/code, specified by its name.
+ *
+ * @param targetName a codeString/code value that must be the
+ * codeObjectName/code of a codeConfigurationStore/code
+ * @param moduleFile a codeFile/code value
+ * @param planFile a codeFile/code value
+ * @return a codeList/code of URI-format codeString/code.
+ * @exception DeploymentException if an error occurs
+ */
+public List deploy(String targetName, File moduleFile, File planFile)
throws DeploymentException {
+ConfigurationStore store = findConfigStore(targetName);
+return deploy(planFile, moduleFile, null, true, null, null, null,
null, store);
+}
+
+
+/**
+ * Deploy the specified module/plan to the specified
+ * codeConfigurationStore/code.
+ *
+ * @param store a codeConfigurationStore/code value
+ * @param moduleFile a codeFile/code value
+ * @param planFile a codeFile/code value
+ * @return a codeList/code of URI-format codeString/code.
+ * @exception DeploymentException if an error occurs
+ */
+List deploy(ConfigurationStore store, File moduleFile, File planFile)
throws DeploymentException {
File originalModuleFile = moduleFile;
File tmpDir = null;
if (moduleFile != null
Re: list-targets command
Hmm, I would have thought that you would want the configurationManager to have several config-stores (I think it does) but to pick one particular one for each deployer. How does the deployer choose which one to put the new config into? thanks david jencks On Dec 5, 2005, at 1:53 PM, toby cabot wrote: Thanks Aaron and David, I've modified o.a.g.client.builder.AppClientModuleBuilder and o.a.g.deployment.Deployer to accept multiple ConfigurationStore references, so now Geronimo will run with two ConfigurationStores specified in system-plan.xml. As you guys expected, you can pass a Target to the deployment cli and it gets passed to DeploymentManager.distribute() but it's lost on the server side since the Deploy.deploy() method that gets called doesn't take a target parameter. I'm a little fuzzy on the theory of operations on the server side - i.e. how the data gets from the wire to Deployer.deploy(). It looks like it uses MX4J but if one of you could sketch out how that code gets set up I could take a look at adding the target code to Deploy tomorrow. Thanks, Toby PS. Please feel free to move this conversation over to the dev list if that's a more appropriate place for it.
Re: list-targets command
On Mon, Dec 05, 2005 at 02:13:33PM -0800, David Jencks wrote: Hmm, I would have thought that you would want the configurationManager to have several config-stores (I think it does) but to pick one particular one for each deployer. How does the deployer choose which one to put the new config into? I don't know. Taking the practical approach, I just tried adding a second ConfigurationStore to system-plan.xml, and at that point the server wouldn't start because a couple of components expected a single ConfigurationStore thart they were provided via GBean references. It sounds as if you're proposing that each Deployer be configured with a more specific reference so that there's a 1-1 relationship between Deployers and ConfigurationStores, whereas I was thinking more along the lines of a single Deployer that knew about multiple configuration stores. Your idea sounds fine, but what's the mechanism at runtime that chooses which deployer to use based on the target? I'm guess I'm not clear on the relationship between the configurationManager and the Deployer(s). When I looked at the backtrace from the Deployer.deploy() method I didn't see the ConfigurationManager in it. Does the configurationManager have an opportunity to delegate certain ConfigurationStores to certain Deployers? Thanks, Toby
Re: list-targets command
On Dec 5, 2005, at 2:41 PM, toby cabot wrote: On Mon, Dec 05, 2005 at 02:13:33PM -0800, David Jencks wrote: Hmm, I would have thought that you would want the configurationManager to have several config-stores (I think it does) but to pick one particular one for each deployer. How does the deployer choose which one to put the new config into? I don't know. Taking the practical approach, I just tried adding a second ConfigurationStore to system-plan.xml, and at that point the server wouldn't start because a couple of components expected a single ConfigurationStore thart they were provided via GBean references. It sounds as if you're proposing that each Deployer be configured with a more specific reference so that there's a 1-1 relationship between Deployers and ConfigurationStores, whereas I was thinking more along the lines of a single Deployer that knew about multiple configuration stores. Your idea sounds fine, but what's the mechanism at runtime that chooses which deployer to use based on the target? I'm guess I'm not clear on the relationship between the configurationManager and the Deployer(s). When I looked at the backtrace from the Deployer.deploy() method I didn't see the ConfigurationManager in it. Does the configurationManager have an opportunity to delegate certain ConfigurationStores to certain Deployers? no The configuration manager is responsible for running the server using stuff that is available in all the repos and config stores it knows about. The deployers only need to know where to put the completed configuration when they are done with it. If they know about more than one, I don't know how they could decide. My understanding of what this could be used for is something like a shared immutable config-store used for official configurations and a non-shared config-store you could put your own stuff into. In this case, the deployer would point at the non-shared config store. Very likely we could make the immutable config-store based off the geronimo repo using packed car files directly. I've forgotten what you originally wanted this for, could you remind me? thanks david jencks Thanks, Toby
Re: list-targets command
On 12/5/05, David Jencks [EMAIL PROTECTED] wrote: The configuration manager is responsible for running the server using stuff that is available in all the repos and config stores it knows about. The deployers only need to know where to put the completed configuration when they are done with it. If they know about more than one, I don't know how they could decide. The JSR-88 deployment API accepts a target parameter, and for us, the target corresponds to a config store. So we can pass that on in the call to the Deployer GBean, which would then know which config store to use. Aaron My understanding of what this could be used for is something like a shared immutable config-store used for official configurations and a non-shared config-store you could put your own stuff into. In this case, the deployer would point at the non-shared config store. Very likely we could make the immutable config-store based off the geronimo repo using packed car files directly. I've forgotten what you originally wanted this for, could you remind me? thanks david jencks Thanks, Toby
Re: list-targets command
On Mon, Dec 05, 2005 at 02:51:00PM -0800, David Jencks wrote: My understanding of what this could be used for is something like a shared immutable config-store used for official configurations and a non-shared config-store you could put your own stuff into. In this case, the deployer would point at the non-shared config store. Very likely we could make the immutable config-store based off the geronimo repo using packed car files directly. I've forgotten what you originally wanted this for, could you remind me? I'm looking at doing something similar to this. I deploy one application at my build-time, then package up Geronimo (along with a bunch of other code) and run it on a read-only partition, with various log files, etc moved to a read-write partition. This has worked fine for since I haven't (up till now) had to worry about adding or removing applications, but that requirement's coming down the pipe. So I'd like to have two config-stores, one for my code (read-only i.e. can't be undeployed) and one read-write. It's not important to me how things are stored in the config-stores, just that I be able to specify them when I deploy. Thanks, Toby
Re: list-targets command
On Mon, Dec 05, 2005 at 06:00:49PM -0500, Aaron Mulder wrote: The JSR-88 deployment API accepts a target parameter, and for us, the target corresponds to a config store. So we can pass that on in the call to the Deployer GBean, which would then know which config store to use. Cool! Is it as simple as adding a new deploy() method or is there some configuration of MX4J that I need to do? Thanks, Toby
Re: list-targets command
On 12/5/05, toby cabot [EMAIL PROTECTED] wrote: Cool! Is it as simple as adding a new deploy() method or is there some configuration of MX4J that I need to do? I haven't looked at the deploy method to see how challenging it will be to get the Deployer to do the right thing if you *do* pass it a config store reference. But no MX4J configuration should be required. Aaron
