geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Kirby" <>
Subject Re: Property substitution in config.xml implemented
Date Tue, 06 Mar 2007 13:32:42 GMT
On 3/5/07, David Jencks <> wrote:
> 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
> 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.

+1.  I like this for system properties.

I share your ambivalence towards environment variables.  Scripts have
no system properties, so environment variables are the only choice.
For our java server code, we could consider not supporting environment
variables.  If the user wants to use environment variables, s/he can
always use -D{system property}=${environment variable} to set a system
property from an environment variable.  There seem to be many
environment variables, so doing this provides safety from picking up
an unintended value from the environment.  On the other hand, using
long variable names as you describe above would provide some
protection from this concern.  Would your parsing of environment
variable names be case sensitive?  Environment variable names
generally seem to be upper case.  Using lower case may give us further
name-space isolation and protection from unintended consequences.

> 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.

I am concerned with two cases:

1. How does a user know what substitution variables are in effect so
he can choose one not already in use?
Searching for the name in config.xml will solve the problem.  Further,
I recently realized that the properties file will have a list of
variables used.  The caveat here is that, IIUC, JEXL will silently
handle undefined values, so a used variable need not be listed in the
properties file.  I think this is unfortunate for our usage here.

2. Say in release X, the user uses a new variable A, which we did not
use, and in release X+1, we now define variable A.  As part of a
careful migration strategy, the user should diff config.xml to see
what has changed.  Note that here, a release may be as small as a

While these are minor concerns with pretty easy manual means of
prevention (not sure about problem detection and determination), a
naming convention allows problem avoidance, as well as eliminates some
manual intervention.  It's good to discuss naming conventions at the
time of feature introduction...

Ted Kirby

> 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
> >
> >

View raw message