Return-Path: 
 <avalon-phoenix-dev-return-698-qmlist-jakarta-archive-avalon-phoenix-dev=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-avalon-phoenix-dev-archive@apache.org
Received: (qmail 69819 invoked from network); 16 Jul 2002 19:23:13 -0000
Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131)
  by daedalus.apache.org with SMTP; 16 Jul 2002 19:23:13 -0000
Received: (qmail 16240 invoked by uid 97); 16 Jul 2002 19:23:31 -0000
Delivered-To: qmlist-jakarta-archive-avalon-phoenix-dev@jakarta.apache.org
Received: (qmail 16217 invoked by uid 97); 16 Jul 2002 19:23:30 -0000
Mailing-List: contact avalon-phoenix-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:avalon-phoenix-dev-subscribe@jakarta.apache.org>
List-Help: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>
List-Post: <mailto:avalon-phoenix-dev@jakarta.apache.org>
List-Id: "Avalon-Phoenix Developers List"
 <avalon-phoenix-dev.jakarta.apache.org>
Reply-To: "Avalon-Phoenix Developers List"
 <avalon-phoenix-dev@jakarta.apache.org>
Delivered-To: mailing list avalon-phoenix-dev@jakarta.apache.org
Received: (qmail 16205 invoked by uid 98); 16 Jul 2002 19:23:30 -0000
X-Antivirus: nagoya (v4198 created Apr 24 2002)
Content-Type: text/plain;
  charset="us-ascii"
From: Peter Royal <proyal@apache.org>
To: avalon-phoenix-dev@jakarta.apache.org
Subject: MergedConfiguration + FileSystemPersistentConfigurationRepository
Date: Tue, 16 Jul 2002 14:33:51 -0400
User-Agent: KMail/1.4.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <200207161433.51290.proyal@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

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 instances. 

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 default, it 
will be PHOENIX_HOME/conf/apps/<appname>/<block>.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 saved 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 the "base" (layer 
== from conf/apps..., base == from SAR-INF/config.xml).

Why MergedConfiguration and not CascadingConfiguration? You can read the 
massive thread on how configurations should be merged/cascaded 
(http://marc.theaimsgroup.com/?l=avalon-dev&m=101368753622021&w=2), 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: <a><b x="1"/></a>
Base: <a><b/></a>
Result: <a><b x="1"/><b/></a>

when using Configuration.getChild(name), CascadingConfiguration would do the 
right thing, but it didn't even attempt to when using 
Configuration.getChildren. We need a sane result from getChildren because we 
serialize the merged configurations when validating them. In the above 
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. But with 
the magic attribute on the layer:

<a><b x="1" phoenix-configuration:merge="true"/></a> 

the result will be:

<a><b x="1"/></a>

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 merged *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 to true. In 
the near future, I will be adding the ability to merge children with the same 
getName() by defining a "key" attribute to compare against, ala:

Layer: 
<a>
  <b x="1" phoenix-configuration:merge="true" 
phoenix-configuration:key-attribute="x">
    <c>
  </b>
  <b x="2"/>
</a>

Base: 
<a>
  <b x="1"/>
  <b x="2"/>
</a>

thus in order to merge <b x="1"/>, the name must be the same *and* the 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

-- 
peter royal -> proyal@apache.org

--
To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>