Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 36430 invoked from network); 5 Dec 2005 22:51:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 5 Dec 2005 22:51:32 -0000 Received: (qmail 38202 invoked by uid 500); 5 Dec 2005 22:51:28 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 38162 invoked by uid 500); 5 Dec 2005 22:51:28 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 38151 invoked by uid 99); 5 Dec 2005 22:51:28 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Dec 2005 14:51:28 -0800 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [216.136.174.115] (HELO smtp018.mail.yahoo.com) (216.136.174.115) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 05 Dec 2005 14:51:26 -0800 Received: (qmail 13676 invoked from network); 5 Dec 2005 22:51:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer; b=ajagzBGLJzK9IGeGDfOM4jwI7vkhXiNzeOIXQKir/ScXQricH8HYowTuSROtJeLhs4yJ17An58orlVZTyb6HiEao95hRWTT3FsZtHSSvHQ/DXYLQPBmlwVX5g0ijyRkPV/FBgxCiJNM3ABM9YMbC56Qrft2uvfEW1tz4T1tOwOk= ; Received: from unknown (HELO ?192.168.1.5?) (david?jencks@66.93.38.137 with plain) by smtp018.mail.yahoo.com with SMTP; 5 Dec 2005 22:51:06 -0000 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <20051205224151.GA26176@caboteria.org> References: <74e15baa0511211124o7aaf36fcv6cfbac33f1a5598f@mail.gmail.com> <20051202201220.GA16035@caboteria.org> <1a4017e818c64eaf8fa311bc94fb84ed@yahoo.com> <20051205215327.GA25287@caboteria.org> <383e66675130d4d70427f94263d253d7@yahoo.com> <20051205224151.GA26176@caboteria.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David Jencks Subject: Re: list-targets command Date: Mon, 5 Dec 2005 14:51:00 -0800 To: dev@geronimo.apache.org X-Mailer: Apple Mail (2.622) X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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 >