You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <do...@apache.org> on 2001/04/16 14:17:15 UTC
[Phoenix] Configuration - to template or not ?
Hi,
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.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [Phoenix] Configuration - to template or not ?
Posted by Peter Donald <do...@apache.org>.
At 02:44 16/4/01 +0200, Stephen McConnell wrote:
>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.
Actually I wasn't proposing that exactly ;) I was actually just proposing
that config be in a separate file ;) We could still do a block per file I
guess by having something like
<!DOCTYPE project
[
<!ENTITY block1 SYSTEM "block1.xml">
<!ENTITY block2 SYSTEM "block2.xml">
]>
<configuration>
&block1;
&block2;
&block3;
</configuration>
>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
We talked about adding constants with respect to Berins proposal but as we
never got around to that it never got implemented ;) It is especially
painful when you have to copy the same property into multiple places (ie
dns name for HELO message, interface to be bound to etc ...).
> 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.
Will Normal XML Entity level includes suffice (like above) or how about
something more? The only *clean* way of doing it was with something like
XSL which I am a little hesitant to implement at the moment.
>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
in some servers yes ... some may include other stuff in .sar other than
code/config. (Say web-pages for web-server). How we do it is another
question ;)
>i.e. is it possible to load these resources from the .sar file directly.
yep.
>If this is possible it would eliminate some level of
>complexity simply through not exposing what is happening at the file system
>level.
agreed.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Phoenix] Configuration - to template or not ?
Posted by Charles Benett <ch...@benett1.demon.co.uk>.
Peter Donald wrote:
>
> Hi,
>
> 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>
>
If you mean every block for a sar is mentioned in its assembly.xml and
each block has its own config.xml, that is fine: +1
> 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.
I would strongly prefer everything to work out of the box. I think it
makes a big difference to newbies whether to avalon or avalon based
systems like James. So +1 for fully configured instance. (Of course,
people who need to change it could still do that.)
>
> 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.
How are you going to configure the configuration? Ie will there be a
file that points at an LDAP server/ DB etc?
-1 for updating filesystem sar with real config - it would be confusing
to work out what to change.
If an avalon instance is using LDAP/db whatever, then I suggest copying
the config.xml templates into another directory.
Better yet: have two copies of config.xml One in a conf dir which is
read if configuring from filesystem and deleted if configuring from
elsewhere. The second in another dir - docs? - which is the avalon
provided original. This would be both a template (if someone reverts
from LDAP/db to filesystem) and a backup in case they munge the version
in conf dir.
Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [Phoenix] Configuration - to template or not ?
Posted by Stephen McConnell <mc...@osm.net>.
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>
+1
>
> 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
level.
Cheers, Steve.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org