avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen McConnell" <mcconn...@osm.net>
Subject RE: [Phoenix] Configuration - to template or not ?
Date Mon, 16 Apr 2001 12:44:27 GMT

Peter Donald wrote:
> I am just about to rework some stuff in Phoenixs core again to make it
> possible to store/retrieve configuration from wherever. A few
> points points
> must be decided. I had originally planned to separate the config out into
> conf/config.xml. The config would simple be the configuration element from
> the assembly.xml file  in another file under an element name coresponding
> to block name.
> Hence foo block which now looks like
> <block name="foo" class="com.biz.FooBlock">
>   <provide .. />
>   <provide .. />
>   <configuration>
>     <a>
>       <b>some text</b>
>     </a>
>   </configuration>
> </block>
> would now be separated into
> assembly.xml:
> <block name="foo" class="com.biz.FooBlock">
>   <provide .. />
>   <provide .. />
> </block>
> config.xml:
> <foo>
>   <a>
>     <b>some text</b>
>   </a>
> </foo>


> Now another point that needs addressing is what we consider config.xml to
> be ..  a template or a fully configured instance. The J2EE jars (ie War et
> al) consider it a fully configured instance. They have tools that take the
> jar and massage it ***before*** deploying. At one stage there was talk of
> having ours as a template which you configure after installing/deploying
> ... thoughts?? Which is better.
> Another question - if we are storing configuration data in
> LDAP/DB/whatever
> then do we leave the config.xml on filesystem or delete it. Do we update
> the filesystem/.sar with "real" configuration after each change etc.

I'm not at all sure if this is answering your question - but the following
it a little summary of our experience to-date.  Firstly, the idea above to
have configuration files per block will be a big plus.  Our current server
assembly.xml file is currently about 1,500 lines. There are a few things
that could improve manageability of the content:

	1.  Ant style properties, i.e. the ability to define
          a single property and have that property propagated
          across several block configurations

      2.  The ability for one configuration file to extend
          another.  The reason for this is that some aspects
          of our configuration are great for developers who
          want to extend the platform, other aspects are more
          oriented towards the declaration of company policy.

Beyond the question of how configuration information is managed, I seem to
remember an email a while ago that was discussing the need to "unpack" the
.sar file.  Aside from configuration info, is there a necessity to unpack
jar and bar files - i.e. is it possible to load these resources from the
.sar file directly.  If this is possible it would eliminate some level of
complexity simply through not exposing what is happening at the file system

Cheers, Steve.

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

View raw message