You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Marcus Crafter <cr...@fztig938.bank.dresdner.net> on 2002/02/22 16:23:27 UTC
Proposal for globals in conf files ?
Hi All,
Hope all is well.
Currently in our project we're doing an internal migration from
hand made classes to avalon components (yippee!).
We've come across the occasion several times where we would like to
access a global configuration value, set outside of that
components configuration hierarchy in an xconf file.
I've brought this up before in an earlier post, and a
suggestion from Giacomo was to use ECM's Context to store these global
values.
I like this idea, but it means having to manually read the
configuration file before passing it onwards to ECM.
No problem, but how about automating this a little by enhancing
ECM/ComponentManager so that root level attributes in xconf files are
automatically added to ECM's Context ?
ie:
<application version="value" variable1="value" variable2="">
<component>
...
</component>
...
...
</application>
...
String version = this.context.get("version");
This would remove the need to do this step manually, and would
provide a nice place for globals.
Thoughts ? Comments ?
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Proposal for globals in conf files ?
Posted by Berin Loritsch <bl...@apache.org>.
Marcus Crafter wrote:
> Nice, it's a little more elaborate and I like it.
>
> Multiple argument constructors could be done with Parameters:
>
> <entry name="server" type="our.server.class.name">
> <Parameter value="our.machine.name"/>
> <Parameter value="our.machine.port"/>
> </entry>
>
> (hmm.. but is the parsing order guarenteed ?)
>
> Representing non-string constants is a little tough though
> (eg. does value="1" mean the string "1" or the integer value 1 ?).
>
> One would almost have to follow something like JNI's representation
> for objects, eg. value="java/lang/String|14" which isn't so nice, or
> drop non-string values alltogether. Supporting non-primitive argument
> types is another issue alltogether. :(
In the our.machine.port example, if the entry type was
"java.lang.Integer" (as it would have to be for contexts)
it would work.
Also, the parsing order follows the same semantics as the XML parsing
order. So the answer is yes.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Proposal for globals in conf files ?
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
On Fri, Feb 22, 2002 at 10:36:09AM -0500, Berin Loritsch wrote:
> Marcus Crafter wrote:
> >
> > No problem, but how about automating this a little by enhancing
> > ECM/ComponentManager so that root level attributes in xconf files are
> > automatically added to ECM's Context ?
> >
> > <application version="value" variable1="value" variable2="">
> > <component>
> > ...
> > </component>
> > ...
> > ...
> > </application>
> >
> > ...
> >
> > String version = this.context.get("version");
> >
> > This would remove the need to do this step manually, and would
> > provide a nice place for globals.
>
> It would be possible, and every container has their own requirements.
> With the ContainerManager work going on, you would extend the configure
> method and extract what you need ahead of time. You also have to
> consider that Context does not limit you to strings. So how would you
> represent non-string constants?
>
> To make it clear what are global values, I would do something like this:
>
> <application>
> <context><!-- can be renamed to "global" or whatever -->
> <!-- defaults to string -->
> <entry name="version" value="1.0.3"/>
> <entry name="work-dir" value="/tmp/application/${version}/"
> type="java.io.File"/>
> <!-- Type must accept 1 string in constructor -->
> </context>
> <component/>
> </application>
Nice, it's a little more elaborate and I like it.
Multiple argument constructors could be done with Parameters:
<entry name="server" type="our.server.class.name">
<Parameter value="our.machine.name"/>
<Parameter value="our.machine.port"/>
</entry>
(hmm.. but is the parsing order guarenteed ?)
Representing non-string constants is a little tough though
(eg. does value="1" mean the string "1" or the integer value 1 ?).
One would almost have to follow something like JNI's representation
for objects, eg. value="java/lang/String|14" which isn't so nice, or
drop non-string values alltogether. Supporting non-primitive argument
types is another issue alltogether. :(
> This would allow you to resolve your context values with other entries
> (already available with Context), as well as have additional types than
> simply String--provided that the constructor accepts one String in the
> constructor.
Yes. Are you suggesting this be a general ContainerManager
enhancement, or something I should write locally ?
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Proposal for globals in conf files ?
Posted by Berin Loritsch <bl...@apache.org>.
Marcus Crafter wrote:
> Hi All,
>
> Hope all is well.
>
> Currently in our project we're doing an internal migration from
> hand made classes to avalon components (yippee!).
>
> We've come across the occasion several times where we would like to
> access a global configuration value, set outside of that
> components configuration hierarchy in an xconf file.
>
> I've brought this up before in an earlier post, and a
> suggestion from Giacomo was to use ECM's Context to store these global
> values.
>
> I like this idea, but it means having to manually read the
> configuration file before passing it onwards to ECM.
>
> No problem, but how about automating this a little by enhancing
> ECM/ComponentManager so that root level attributes in xconf files are
> automatically added to ECM's Context ?
>
> ie:
>
> <application version="value" variable1="value" variable2="">
> <component>
> ...
> </component>
> ...
> ...
> </application>
>
> ...
>
> String version = this.context.get("version");
>
> This would remove the need to do this step manually, and would
> provide a nice place for globals.
It would be possible, and every container has their own requirements.
With the ContainerManager work going on, you would extend the configure
method and extract what you need ahead of time. You also have to
consider that Context does not limit you to strings. So how would you
represent non-string constants?
To make it clear what are global values, I would do something like this:
<application>
<context><!-- can be renamed to "global" or whatever -->
<!-- defaults to string -->
<entry name="version" value="1.0.3"/>
<entry name="work-dir" value="/tmp/application/${version}/"
type="java.io.File"/>
<!-- Type must accept 1 string in constructor -->
</context>
<component/>
</application>
This would allow you to resolve your context values with other entries
(already available with Context), as well as have additional types than
simply String--provided that the constructor accepts one String in the
constructor.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>