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 -- Cheers, 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
