Return-Path: Delivered-To: apmail-jakarta-avalon-phoenix-dev-archive@apache.org Received: (qmail 99852 invoked from network); 19 Jul 2002 00:40:57 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 19 Jul 2002 00:40:57 -0000 Received: (qmail 10866 invoked by uid 97); 19 Jul 2002 00:41:18 -0000 Delivered-To: qmlist-jakarta-archive-avalon-phoenix-dev@jakarta.apache.org Received: (qmail 10843 invoked by uid 97); 19 Jul 2002 00:41:18 -0000 Mailing-List: contact avalon-phoenix-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon-Phoenix Developers List" Reply-To: "Avalon-Phoenix Developers List" Delivered-To: mailing list avalon-phoenix-dev@jakarta.apache.org Received: (qmail 10828 invoked by uid 98); 19 Jul 2002 00:41:17 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Content-Type: text/plain; charset="iso-8859-1" From: Peter Donald To: "Avalon-Phoenix Developers List" Subject: Re: MergedConfiguration + FileSystemPersistentConfigurationRepository Date: Fri, 19 Jul 2002 10:41:20 +1000 User-Agent: KMail/1.4.2 References: <200207161433.51290.proyal@apache.org> In-Reply-To: <200207161433.51290.proyal@apache.org> X-Wisdom: A right is not what someone gives you; it's what no one can take from you. MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200207191041.20384.peter@apache.org> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Finally read through it all. It would be useful if you could extract the=20 MergedConfiguration text from this email and chuck it into an xml file ;) On Wed, 17 Jul 2002 04:33, Peter Royal wrote: > Okay two bits added today, one new one updated. > > First the long named one, FileSystemPersistentConfigurationRepository. = This > is a ConfigurationRepository implementation that stores configuration > information for blocks between phoenix invocations / running app instan= ces. > > Say you have app X that you deploy to your customers, and you have to > configure the jdbc URL inside of config.xml, its a pain, especially if = your > customers are non-techies. Upgrading is a pain too, since you need to > migrate their personal settings that are located inside the SAR. > > Here's a solution, persist that information *outside* the SAR. By defau= lt, > it will be PHOENIX_HOME/conf/apps//.xml > > presto! > > Now you can ship a SAR w/o a jdbc URL and create a single xml document = in > the right spot (jmx management forthcoming) and the config will be save= d > between different copies of the SAR. > > How does it work you ask? Well, it uses the new MergedConfiguration. > Similar to the CascadingConfiguration, except it employs some metadata > (specially named attributes) in the "layer" that is being merged with t= he > "base" (layer =3D=3D from conf/apps..., base =3D=3D from SAR-INF/config= =2Exml). > > Why MergedConfiguration and not CascadingConfiguration? You can read th= e > massive thread on how configurations should be merged/cascaded > (http://marc.theaimsgroup.com/?l=3Davalon-dev&m=3D101368753622021&w=3D2= ), or just > what's below.... > > The CascadingConfiguration did not attempt to handle the specific case > mentioned in the link above, which is namely the following situation: > > Layer: > Base: > Result: > > when using Configuration.getChild(name), CascadingConfiguration would d= o > the right thing, but it didn't even attempt to when using > Configuration.getChildren. We need a sane result from getChildren becau= se > we serialize the merged configurations when validating them. In the abo= ve > example, the result expected should probably be the same as the layer. > > But how do we know that's what the user wants? We don't (at least I'm > missing the ESP module for my laptop). Thus the metadata. > > MergedConfiguration will use a specially named attribte > (phoenix-configuration:merge) to control the merging of layer children = with > base children. For the example above, you will get the result above. Bu= t > with the magic attribute on the layer: > > > > the result will be: > > > > Actually the phoenix-configuration:merge attribute is still there, but = it > is only visible via the getAttribute(), getAttributeAs*() methods, *NOT= * > getAttributeNames(). Why? Serialization :) Having such attributes will > break validation. > > Currently, a child from the layer and a child from the base will be mer= ged > *IF AND ONLY IF* there is only a *SINGLE* child with the same getName()= in > both the layer and child *AND* the phoenix-configuration:merge is set t= o > true. In the near future, I will be adding the ability to merge childre= n > with the same getName() by defining a "key" attribute to compare agains= t, > ala: > > Layer: > > phoenix-configuration:key-attribute=3D"x"> > > > > > > Base: > > > > > > thus in order to merge , the name must be the same *and* th= e x > attribute must have the same value. > > -o- > > I hope that all makes sense, if in doubt ask questions and look at the > code. > > Next up, modifying the persistent configurations via JMX. > -pete --=20 Cheers, Peter Donald --------------------------------------------------- Murphy's law - "Anything that can go wrong, will."=20 (Actually, this is Finagle's law, which in itself=20 shows that Finagle was right.) --------------------------------------------------- -- To unsubscribe, e-mail: For additional commands, e-mail: