avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: MergedConfiguration + FileSystemPersistentConfigurationRepository
Date Fri, 19 Jul 2002 00:41:20 GMT
Finally read through it all. It would be useful if you could extract the 
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 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 Donald
Murphy's law - "Anything that can go wrong, will." 
(Actually, this is Finagle's law, which in itself 
shows that Finagle was right.)

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>

View raw message