On Mar 5, 2007, at 1:26 PM, Ted Kirby wrote:
<snip> One question I have is whether it's really a good idea to use
> environment variables for substitutions. I really don't know and
> would appreciate more informed opinions.
>
> Also, you can specify an alternate properties file on the command
> line with
>
> java -
Dorg.apache.geronimo.config.substitutions.file=where.ever.you.want
Should we consider a naming convention? I find
org.apache.geronimo.config.substitutions.file to be long, but I do
like the name space qualification that org.apache.geronimo provides.
Perhaps oag. could be used for short?
I would like to see some way to have a separate name space for system
properties/variables, like your portOffset above, and those that users
might use and define. For example, we could say that ag properties
like portOffset and those you will use to parameterize the config.xml
we ship, be prefixed by _. Users would not have to worry about a
naming collision if any variable name they use does not start with _.
I like the example of using a system property to override or provide a
value. The other ag system properties are prefixed by
org.apache.geronimo. (See my earlier comment.) Doing that in
config.xml, while long-winded, does provide name space isolation.
Perhaps not using org.apache.geronimo implies the variable only
applies to config.xml substitution, and has no other
interpretation/usage inside the server java code.
Although for different reasons, I like the idea of a namespace prefix
for environment variables and system properties. I have been very
worried that someone is going to have an env var httpPort for some
other purpose and be rather surprised when it changes geronimo
behavior. I'm not really worried about the length of these property
names. I don't think including the prefix in config.xml serves any
purpose.
So, I'd propose that the local attribute manager looks for system
properties and env vars starting with
org.apache.geronimo.config.value.
and when found strip off the prefix and use the remainder as the
property name.
At the moment I don't see the value in trying to distinguish kinds of
substitution variables and having a naming convention for the
different kinds. All the variables can be specified in the
properties file, as an env var, or as a system property, and I think
it really depends on your use case whether you are more likely to
override httpPort or portOffset on the command line.
A further enhancement I thought of that I think I'd rather not pursue
at this time is to allow specifying the artifactId part of the module
name in the key. I think this is too complicated for the value added.
thanks
david jencks
Ted Kirby
> Many thanks to ted for coming up with the original patch and
pushing
> for it.
>
> thanks
> david jencks
>
>
