Return-Path: Delivered-To: apmail-geronimo-user-archive@www.apache.org Received: (qmail 90887 invoked from network); 30 Jan 2008 14:07:27 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 30 Jan 2008 14:07:27 -0000 Received: (qmail 59533 invoked by uid 500); 30 Jan 2008 14:07:17 -0000 Delivered-To: apmail-geronimo-user-archive@geronimo.apache.org Received: (qmail 59512 invoked by uid 500); 30 Jan 2008 14:07:17 -0000 Mailing-List: contact user-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: user@geronimo.apache.org List-Id: Delivered-To: mailing list user@geronimo.apache.org Received: (qmail 59501 invoked by uid 99); 30 Jan 2008 14:07:17 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 30 Jan 2008 06:07:17 -0800 X-ASF-Spam-Status: No, hits=4.0 required=10.0 tests=DNS_FROM_OPENWHOIS,FORGED_YAHOO_RCVD,SPF_HELO_PASS,SPF_PASS,WHOIS_MYPRIVREG X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of lists@nabble.com designates 216.139.236.158 as permitted sender) Received: from [216.139.236.158] (HELO kuber.nabble.com) (216.139.236.158) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 30 Jan 2008 14:07:02 +0000 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1JKDaZ-0002qs-6d for user@geronimo.apache.org; Wed, 30 Jan 2008 06:06:55 -0800 Message-ID: <15182889.post@talk.nabble.com> Date: Wed, 30 Jan 2008 06:06:55 -0800 (PST) From: Stuart Smith To: user@geronimo.apache.org Subject: Re: Merging deployment plans In-Reply-To: <21A5E98A-2BCC-4183-B597-5AAF23F4B2A6@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: stuart_wildcat@yahoo.com References: <15176087.post@talk.nabble.com> <21A5E98A-2BCC-4183-B597-5AAF23F4B2A6@yahoo.com> X-Virus-Checked: Checked by ClamAV on apache.org I don't have any specific use cases just yet. I just wanted to see what the boundaries are. Knowing that an external deployment plan means that any inside the module is ignored helps. Mainly I was thinking about anything app-specific that it would be better an administrator, by supplying an external deployment plan, should not be configuring. Any server properties would probably be altered using the substitution methods you described and not in a deployment plan. Thanks, Stuart djencks wrote: > > Hi Stuart, > > Right now if you supply an external deployment plan any equivalent > inside the javaee app or module is ignored. In general nothing is > merged. However, you can mix up bits to some extent. For instance, > for an ear, you could have an external ear plan that did not include > "sub-plans" for some modules, and have the plans for those modules > inside the modules. > > What specifically were you thinking of altering? Rather than > modifying the plan you might be able to use some of the plugin > features. Basically you can arrange to modify gbean attributes from > entries in the var/config/config-substitutions.properties file. > There's sort of a 3 step process (in geronimo 2.1, soon to be released): > > - identify the gbean you want to configure in your app. Everything's > a gbean, but many gbean for javaee components are not that easy to > configure directly as gbeans, so this idea may or may not be > appropriate for you. > - in the geronimo-plugin.xml specify a module to be copied into var/ > config/config.xml that includes gbean configuration for the > attributes you want to be able to modify, with variables like > ${MySpecialPort} > - also specify entries to be added to var/config/config- > substitutions.properties > 2000 > > When you install your app-built-into-a-plugin into geronimo the > config.xml stuff will go into config.xml, the variables will get into > config-substitutions, and you will be able to customize the values by > modifying config-substitutions. > > This is not a terribly complete explanation, so let me know if this > sounds interesting and hopefully I will have written up more > comprehensible documentation. > > thanks > david jencks > > On Jan 29, 2008, at 10:00 PM, Stuart Smith wrote: > >> >> I've been investigating some of the unique features that make >> Geronimo easier >> to use than JBoss. One of the features that has caught my >> attention is the >> ability to use external deployment information during the deployment >> process. >> >> What I'm wondering is if it is possible to have a deployment plan >> that is >> packaged with an application archive AND one that is external. I'm >> thinking >> anything that is always going to be the same can be in the internal >> deployment plan. Anything that may change from one environment to >> the next >> can be in the external plan. >> >> If this is possible would they be merged into a unified deployment >> plan >> during deployment? Would they be merged with one taking precedence >> over the >> other? Would one be completely ignored if the other is present? >> >> If this type of thing is possible it would be great, if not would >> it be >> possible to add? Many thanks for any replies. >> >> Thanks, >> Stuart >> -- >> View this message in context: http://www.nabble.com/Merging- >> deployment-plans-tp15176087s134p15176087.html >> Sent from the Apache Geronimo - Users mailing list archive at >> Nabble.com. >> > > > -- View this message in context: http://www.nabble.com/Merging-deployment-plans-tp15176087s134p15182889.html Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.