You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <dj...@apache.org> on 2007/03/04 05:47:30 UTC
Property substitution in config.xml implemented
Following Ted Kirby's idea of property substitution in config.xml
files (GERONIMO-2735) I applied and modified his patch. Jason Dillon
had a jexl expression evaluator lying around so I replace the
evaluation code in the patch with the jexl stuff, so now you can use
expressions in your substitutions.
The substitutions are in a new file, default location var/config/
config-substitutions.properties. This is used to evaluate
expressions in config.xml. I implemented a small example in geronimo-
jetty6-jee5 for the jetty connectors, using
hostName
httpPort
httpsPort
portOffset.
You can override a value in the properties file with an environment
variable or a system property. Therefore, to start a server on a
different set of jetty connector ports, you can say:
java -DportOffset=1 -jar bin/server.jar --long
If this generally seems like a good idea and no one has a better idea
I'll go through the config.xmls and use substitutions more
systematically in a few days.
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
Many thanks to ted for coming up with the original patch and pushing
for it.
thanks
david jencks
Re: Property substitution in config.xml implemented
Posted by Ted Kirby <te...@gmail.com>.
On 3/5/07, David Jencks <da...@yahoo.com> 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
> -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.
+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
patch.
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
> >
> >
>
>
>
Re: Property substitution in config.xml implemented
Posted by David Jencks <da...@yahoo.com>.
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
>> >
>> >
>>
Re: Property substitution in config.xml implemented
Posted by Ted Kirby <te...@gmail.com>.
On 3/5/07, Ted Kirby <te...@gmail.com> wrote:
> Brilliant!
> Yeah, this is a great extension to my paltry start... :)
> Thanks,
>
> Ted Kirby
>
> On 3/3/07, David Jencks <dj...@apache.org> wrote:
> > Following Ted Kirby's idea of property substitution in config.xml
> > files (GERONIMO-2735) I applied and modified his patch. Jason Dillon
> > had a jexl expression evaluator lying around so I replace the
> > evaluation code in the patch with the jexl stuff, so now you can use
> > expressions in your substitutions.
> >
> > The substitutions are in a new file, default location var/config/
> > config-substitutions.properties. This is used to evaluate
> > expressions in config.xml. I implemented a small example in geronimo-
> > jetty6-jee5 for the jetty connectors, using
> >
> > hostName
> > httpPort
> > httpsPort
> > portOffset.
> >
> > You can override a value in the properties file with an environment
> > variable or a system property. Therefore, to start a server on a
> > different set of jetty connector ports, you can say:
> >
> > java -DportOffset=1 -jar bin/server.jar --long
>
> I particularly like how this elegantly addresses the multiple server
> instances port numbering issues, to make it very easy to define
> multiple server instances. Just give a server name and port offset,
> and you are set. Now, if I can only locate where port 4200 is set...
> :)
> (See my user posting here
> http://article.gmane.org/gmane.comp.java.geronimo.user/5966 .)
>
> Ted Kirby
>
> > If this generally seems like a good idea and no one has a better idea
> > I'll go through the config.xmls and use substitutions more
> > systematically in a few days.
> >
> > 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.
Ted Kirby
> > Many thanks to ted for coming up with the original patch and pushing
> > for it.
> >
> > thanks
> > david jencks
> >
> >
>
Re: Property substitution in config.xml implemented
Posted by Ted Kirby <te...@gmail.com>.
Brilliant!
Yeah, this is a great extension to my paltry start... :)
Thanks,
Ted Kirby
On 3/3/07, David Jencks <dj...@apache.org> wrote:
> Following Ted Kirby's idea of property substitution in config.xml
> files (GERONIMO-2735) I applied and modified his patch. Jason Dillon
> had a jexl expression evaluator lying around so I replace the
> evaluation code in the patch with the jexl stuff, so now you can use
> expressions in your substitutions.
>
> The substitutions are in a new file, default location var/config/
> config-substitutions.properties. This is used to evaluate
> expressions in config.xml. I implemented a small example in geronimo-
> jetty6-jee5 for the jetty connectors, using
>
> hostName
> httpPort
> httpsPort
> portOffset.
>
> You can override a value in the properties file with an environment
> variable or a system property. Therefore, to start a server on a
> different set of jetty connector ports, you can say:
>
> java -DportOffset=1 -jar bin/server.jar --long
I particularly like how this elegantly addresses the multiple server
instances port numbering issues, to make it very easy to define
multiple server instances. Just give a server name and port offset,
and you are set. Now, if I can only locate where port 4200 is set...
:)
(See my user posting here
http://article.gmane.org/gmane.comp.java.geronimo.user/5966 .)
Ted Kirby
> If this generally seems like a good idea and no one has a better idea
> I'll go through the config.xmls and use substitutions more
> systematically in a few days.
>
> 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
>
> Many thanks to ted for coming up with the original patch and pushing
> for it.
>
> thanks
> david jencks
>
>
Re: Property substitution in config.xml implemented
Posted by Sachin Patel <sp...@gmail.com>.
this is really cool and a huge improvement on what we had previously
-sachin
On Mar 3, 2007, at 11:47 PM, David Jencks wrote:
> Following Ted Kirby's idea of property substitution in config.xml
> files (GERONIMO-2735) I applied and modified his patch. Jason
> Dillon had a jexl expression evaluator lying around so I replace
> the evaluation code in the patch with the jexl stuff, so now you
> can use expressions in your substitutions.
>
> The substitutions are in a new file, default location var/config/
> config-substitutions.properties. This is used to evaluate
> expressions in config.xml. I implemented a small example in
> geronimo-jetty6-jee5 for the jetty connectors, using
>
> hostName
> httpPort
> httpsPort
> portOffset.
>
> You can override a value in the properties file with an environment
> variable or a system property. Therefore, to start a server on a
> different set of jetty connector ports, you can say:
>
> java -DportOffset=1 -jar bin/server.jar --long
>
> If this generally seems like a good idea and no one has a better
> idea I'll go through the config.xmls and use substitutions more
> systematically in a few days.
>
> 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
>
> Many thanks to ted for coming up with the original patch and
> pushing for it.
>
> thanks
> david jencks
>