You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geronimo.apache.org by toby cabot <to...@caboteria.org> on 2005/12/02 21:12:20 UTC

Re: list-targets command

On Mon, Nov 21, 2005 at 02:24:48PM -0500, Aaron Mulder wrote:
> You could in theory have multiple config-stores, for example one
> read-only containing some core modules that are never supposed to
> change and one read-write for new deployments.  However we haven't
> tested that adequately and I'm not convinced it would really work
> properly right now.  I believe we do intend to make this work
> eventually, I just don't think it's on the very short-term horizon.

This could be very useful in my application.  Currently I've got
geronimo running from a read-only partition which works great since
the runtime configuration never changes, but it would be great to be
able to put a configuration store in /var and deploy new applications
there.

How can I help?  Given some pointers as to what's there (and maybe
what's not) I'd be willing to poke around and see what works and what
doesn't.

Thanks,
Toby

Re: list-targets command

Posted by toby cabot <to...@caboteria.org>.
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 (proof of concept)

Posted by toby cabot <to...@caboteria.org>.
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:echo>Bootstrapping 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 @@
             <name>ServerInfo</name>
         </reference>
     </gbean>
+    <gbean name="Local2" class="org.apache.geronimo.system.configuration.LocalConfigStore">
+        <attribute name="root">config-store2</attribute>
+        <reference name="ServerInfo">
+            <name>ServerInfo</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 
+     * <code>ConfigurationStore</code>, specified by its name.
+     *
+     * @param targetName a <code>String</code> value that must be the
+     * <code>ObjectName</code> of a <code>ConfigurationStore</code>
+     * @param moduleFile a <code>File</code> value
+     * @param planFile a <code>File</code> value
+     * @return a <code>List</code> of URI-format <code>String</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
+     * <code>ConfigurationStore</code>.
+     *
+     * @param store a <code>ConfigurationStore</code> value
+     * @param moduleFile a <code>File</code> value
+     * @param planFile a <code>File</code> value
+     * @return a <code>List</code> of URI-format <code>String</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 && !moduleFile.isDirectory()) {
@@ -88,7 +127,7 @@
         }
 
         try {
-            return deploy(planFile, moduleFile, null, true, null, null, null, null);
+            return deploy(planFile, moduleFile, null, true, null, null, null, null, store);
         } catch (DeploymentException e) {
             log.debug("Deployment failed: plan=" + planFile +", module=" + originalModuleFile, e);
             throw e.cleanse();
@@ -172,6 +211,15 @@
     }
 
     public List deploy(File planFile, File moduleFile, File targetFile, boolean install, String mainClass, String classPath, String endorsedDirs, String extensionDirs) throws DeploymentException {
+        return deploy(planFile, moduleFile, targetFile, install, mainClass, classPath, endorsedDirs, extensionDirs, this.defaultStore);
+    }
+
+
+    List deploy(File planFile, File moduleFile, File targetFile, boolean install, String mainClass, String classPath, String endorsedDirs, String extensionDirs, ConfigurationStore store) throws DeploymentException {
+        if (null == store) {
+            throw new DeploymentException("No configuration store specified.");
+        }
+
         if (planFile == null && moduleFile == null) {
             throw new DeploymentException("No plan or module specified");
         }
@@ -298,6 +346,29 @@
         }
     }
 
+
+    /**
+     * Finds the ConfigurationStore that matches the target name provided.
+     *
+     * @param target a <code>String</code> value that describes a
+     * target, usually one of the entries that comes back from the
+     * deployer list-targets command,
+     * e.g. <code>geronimo.server:J2EEApplication=null,J2EEModule=geronimo/system/1.0-SNAPSHOT/car,J2EEServer=geronimo,j2eeType=ConfigurationStore,name=Local</code>
+     * @return a <code>ConfigurationStore</code> value
+     * @exception DeploymentException if an error occurs, probably
+     * because the target provided didn't match any ConfigurationStore
+     */
+    ConfigurationStore findConfigStore(String target) throws DeploymentException {
+        for (Iterator i = stores.iterator(); i.hasNext(); ) {
+            ConfigurationStore candidate = (ConfigurationStore)i.next();
+            if (candidate.getObjectName().equals(target)) {
+                return candidate;
+            }
+        }
+        throw new DeploymentException("no configuration store matches the target name \"" + target + "\"");
+    }
+
+
     public static final GBeanInfo GBEAN_INFO;
 
     private static final String DEPLOYER = "Deployer";
@@ -307,6 +378,7 @@
 
         infoFactory.addAttribute("kernel", Kernel.class, false);
         infoFactory.addAttribute("remoteDeployUploadURL", String.class, false);
+        infoFactory.addOperation("deploy", new Class[]{String.class, File.class, File.class});
         infoFactory.addOperation("deploy", new Class[]{File.class, File.class});
         infoFactory.addOperation("deploy", new Class[]{File.class, File.class, File.class, boolean.class, String.class, String.class, String.class, String.class});
 
Index: modules/deploy-jsr88/src/java/org/apache/geronimo/deployment/plugin/local/AbstractDeployCommand.java
===================================================================
--- modules/deploy-jsr88/src/java/org/apache/geronimo/deployment/plugin/local/AbstractDeployCommand.java	(revision 354583)
+++ modules/deploy-jsr88/src/java/org/apache/geronimo/deployment/plugin/local/AbstractDeployCommand.java	(working copy)
@@ -42,7 +42,7 @@
     private final static String DEPLOYER_NAME = "*:name=Deployer,j2eeType=Deployer,*";
 
     protected final Kernel kernel;
-    private static final String[] DEPLOY_SIG = {File.class.getName(), File.class.getName()};
+    private static final String[] DEPLOY_SIG = {String.class.getName(), File.class.getName(), File.class.getName()};
     protected final boolean spool;
     protected File moduleArchive;
     protected File deploymentPlan;
@@ -101,7 +101,7 @@
     }
 
     protected void doDeploy(Target target, boolean finished) throws Exception {
-        File[] args = {moduleArchive, deploymentPlan};
+        Object[] args = {target.getName(), moduleArchive, deploymentPlan};
         massageFileNames(args);
         List objectNames = (List) kernel.invoke(deployer, "deploy", args, DEPLOY_SIG);
         if (objectNames == null || objectNames.isEmpty()) {
@@ -132,7 +132,7 @@
         }
     }
 
-    protected void massageFileNames(File[] inputs) {
+    protected void massageFileNames(Object[] inputs) {
     }
 
     public URL getRemoteDeployUploadURL() throws Exception {
Index: modules/client-builder/src/java/org/apache/geronimo/client/builder/AppClientModuleBuilder.java
===================================================================
--- modules/client-builder/src/java/org/apache/geronimo/client/builder/AppClientModuleBuilder.java	(revision 354583)
+++ modules/client-builder/src/java/org/apache/geronimo/client/builder/AppClientModuleBuilder.java	(working copy)
@@ -117,7 +117,7 @@
                                   ModuleBuilder connectorModuleBuilder,
                                   ResourceReferenceBuilder resourceReferenceBuilder,
                                   ServiceReferenceBuilder serviceReferenceBuilder,
-                                  ConfigurationStore store,
+                                  Collection stores,
                                   Repository repository,
                                   Kernel kernel) throws DeploymentException {
         this.defaultClientParentId = defaultClientParentId == null? Collections.EMPTY_LIST: Arrays.asList(defaultClientParentId);
@@ -125,7 +125,11 @@
         this.corbaGBeanObjectName = corbaGBeanObjectName;
         this.kernel = kernel;
         this.repository = repository;
-        this.store = store;
+        if (null != stores && stores.size() > 0) {
+            this.store = (ConfigurationStore)stores.iterator().next();
+        } else {
+            this.store = null;
+        }
         this.transactionContextManagerObjectName = transactionContextManagerObjectName;
         this.connectionTrackerObjectName = connectionTrackerObjectName;
         this.ejbReferenceBuilder = ejbReferenceBuilder;

Re: list-targets command

Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 12/5/05, toby cabot <to...@caboteria.org> 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

Re: list-targets command

Posted by toby cabot <to...@caboteria.org>.
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

Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 12/5/05, David Jencks <da...@yahoo.com> 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

Posted by David Jencks <da...@yahoo.com>.
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

Posted by toby cabot <to...@caboteria.org>.
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

Posted by David Jencks <da...@yahoo.com>.
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

Posted by toby cabot <to...@caboteria.org>.
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

Posted by David Jencks <da...@yahoo.com>.
You could start by just trying 2 config stores.  Add another one to the 
j2ee-system plan and rebuild everything.  If the server starts we can 
start worrying about how to put stuff there:-)

I'm very interested in using the geronimo repo as the immutable config 
store: for at least gbean-only configurations I think packed car files 
will work fine.  The MavenConfigStore n the packaging plugin may be 
repurposable for this.

thanks
david jencks

On Dec 2, 2005, at 12:12 PM, toby cabot wrote:

> On Mon, Nov 21, 2005 at 02:24:48PM -0500, Aaron Mulder wrote:
>> You could in theory have multiple config-stores, for example one
>> read-only containing some core modules that are never supposed to
>> change and one read-write for new deployments.  However we haven't
>> tested that adequately and I'm not convinced it would really work
>> properly right now.  I believe we do intend to make this work
>> eventually, I just don't think it's on the very short-term horizon.
>
> This could be very useful in my application.  Currently I've got
> geronimo running from a read-only partition which works great since
> the runtime configuration never changes, but it would be great to be
> able to put a configuration store in /var and deploy new applications
> there.
>
> How can I help?  Given some pointers as to what's there (and maybe
> what's not) I'd be willing to poke around and see what works and what
> doesn't.
>
> Thanks,
> Toby
>