You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Ted Kirby <te...@gmail.com> on 2007/01/19 00:15:56 UTC
Proposal for property substitution in config.xml
The idea is allow an identical configuration on a set of machines, yet allow
customization through property substitution with command line/system
property override (i.e. java -Dxxx.yyy.zzz=ABC).
For example, allow the following in config.xml:
<module name="...">
<gbean name="TomcatConnector">
<attribute name="port">${tomcat.port}</attribute>
<attribute name="host">${tomcat.listen.ip}</attribute>
</gbean>
</module>
These variables are set on server startup via:
java –Dtomcat.port=9090 –Dtomcat.listen.ip=10.0.0.7
JBoss has this capability, and I'd like to bring it to Geronimo.
I have opened JIRA 2735 (https://issues.apache.org/jira/browse/GERONIMO-2735)
for the feature, but I wanted to solicit community input and feedback on
features and implementation.
I think this feature could be pretty easily implemented in GBeanOverride. The
constructor reads the values from config.xml. The values could be parsed
for ${…} constructs. If a known substitution variable is found inside, the
attribute and its unsubstituted value could be saved in an
unsubstitutedAttribute hashmap. The attribute hashmap would contain the
substituted value. This logic can also be applied to the setAttribute
method. The writeXML method is used to write out the config.xml. As it is
processing the attributes hashmap, if the attribute name was found in the
new unsubstitutedAttribute hashmap, write out its value instead.
Thoughts?
Re: Proposal for property substitution in config.xml
Posted by Ted Kirby <te...@gmail.com>.
I just submitted the AG2.0 patch to the JIRA. My question from
AG1.1.1 below remains and is valid for the AG2.0 code, which is
essentially the same.
On 1/25/07, Ted Kirby <te...@gmail.com> wrote:
> I have implemented this support in AG 1.1.1, and submitted the patch
> to the JIRA. I will now work on porting this to AG 2.0, and submit
> that patch when I am done. See the JIRA for some details on what I
> have done. It follows the discussion in this thread.
>
> I have a question. I load the properties in LocalAttributeManager,
> and need to interrogate them in GBeanOverride. How should I access
> them from GBeanOverride? One approach is to pass a reference through
> ServerOverride and ConfigurationOverride. For expediency, I use a
> static getProperty method in LocalAttributeManger. I solicit input on
> a good and proper approach.
>
> On 1/19/07, Ted Kirby <te...@gmail.com> wrote:
> >
> >
> > A properties file sounds like a good idea. Presumably this would work like
> > how the config.xml filename is passed in: from the configFile attribute of
> > the AttributeManager GBean in the j2ee-system module, although it may be
> > overridden by the org.apache.geronimo.config.file system property. The
> > LocalAttributeManager constructor would then read in the properties file,
> > setting up a hashmap for substitution variables and their values.
> >
> > It seems there are three possibilities for value sources: system
> > properties, environment variables and the properties file. We should
> > develop a hierarchal search order for them, which is probably how I listed
> > them. We might add a syntax for specifying the source, although the
> > hierarchy is probably better.
> >
> >
> > On 1/18/07, David Jencks <da...@yahoo.com> wrote:
> > >
> > > This seems reasonable and I think it will work but I'm worried about an
> > infinite regress of configuration systems. Config.xml was supposed to be
> > this handy way to substitute attribute values for the "correct" ones
> > provided in the module plans. Now we're considering overriding these on the
> > command line, and perhaps next we'll be able to specify property files and
> > additional xml files to further customize the configuration not to mention
> > files containing lists of other configuration override files.. Imagining
> > this is making me a little worried. I wonder if a different approach could
> > possibly work better, but I sure don't know what it is. I think it might be
> > useful to figure out exactly what anyone is likely to want to configure in
> > this way. I suspect that it's going to turn out to be the connections to
> > the edges of the system, such as host name/ ip and ports, and db locations.
> > Maybe we should think about configuring those separately in e.g a properties
> > file or something.
> > >
> > >
> > > thanks
> > > david jencks
> > >
> > >
> > >
> > >
> > >
> > > On Jan 18, 2007, at 3:15 PM, Ted Kirby wrote:
> > >
> > >
> > > The idea is allow an identical configuration on a set of machines, yet
> > allow customization through property substitution with command line/system
> > property override ( i.e. java -Dxxx.yyy.zzz=ABC).
> > >
> > >
> > > For example, allow the following in config.xml:
> > >
> > > <module name="...">
> > > <gbean name="TomcatConnector">
> > > <attribute name="port">${ tomcat.port}</attribute>
> > > <attribute name="host">${tomcat.listen.ip}</attribute>
> > > </gbean>
> > > </module>
> > >
> > >
> > > These variables are set on server startup via:
> > > java –Dtomcat.port=9090 –Dtomcat.listen.ip= 10.0.0.7
> > >
> > >
> > > JBoss has this capability, and I'd like to bring it to Geronimo.
> > >
> > >
> > > I have opened JIRA 2735 (
> > https://issues.apache.org/jira/browse/GERONIMO-2735 ) for
> > the feature, but I wanted to solicit community input and feedback on
> > features and implementation.
> > >
> > >
> > > I think this feature could be pretty easily implemented in GBeanOverride .
> > The constructor reads the values from config.xml. The values could be
> > parsed for ${…} constructs. If a known substitution variable is found
> > inside, the attribute and its unsubstituted value could be saved in an
> > unsubstitutedAttribute hashmap. The attribute hashmap would contain the
> > substituted value. This logic can also be applied to the setAttribute
> > method. The writeXML method is used to write out the config.xml. As it is
> > processing the attributes hashmap, if the attribute name was found in the
> > new unsubstitutedAttribute hashmap, write out its value instead.
> > >
> > >
> > > Thoughts?
> > >
> >
> >
>
Re: Proposal for property substitution in config.xml
Posted by Ted Kirby <te...@gmail.com>.
I have implemented this support in AG 1.1.1, and submitted the patch
to the JIRA. I will now work on porting this to AG 2.0, and submit
that patch when I am done. See the JIRA for some details on what I
have done. It follows the discussion in this thread.
I have a question. I load the properties in LocalAttributeManager,
and need to interrogate them in GBeanOverride. How should I access
them from GBeanOverride? One approach is to pass a reference through
ServerOverride and ConfigurationOverride. For expediency, I use a
static getProperty method in LocalAttributeManger. I solicit input on
a good and proper approach.
On 1/19/07, Ted Kirby <te...@gmail.com> wrote:
>
>
> A properties file sounds like a good idea. Presumably this would work like
> how the config.xml filename is passed in: from the configFile attribute of
> the AttributeManager GBean in the j2ee-system module, although it may be
> overridden by the org.apache.geronimo.config.file system property. The
> LocalAttributeManager constructor would then read in the properties file,
> setting up a hashmap for substitution variables and their values.
>
> It seems there are three possibilities for value sources: system
> properties, environment variables and the properties file. We should
> develop a hierarchal search order for them, which is probably how I listed
> them. We might add a syntax for specifying the source, although the
> hierarchy is probably better.
>
>
> On 1/18/07, David Jencks <da...@yahoo.com> wrote:
> >
> > This seems reasonable and I think it will work but I'm worried about an
> infinite regress of configuration systems. Config.xml was supposed to be
> this handy way to substitute attribute values for the "correct" ones
> provided in the module plans. Now we're considering overriding these on the
> command line, and perhaps next we'll be able to specify property files and
> additional xml files to further customize the configuration not to mention
> files containing lists of other configuration override files.. Imagining
> this is making me a little worried. I wonder if a different approach could
> possibly work better, but I sure don't know what it is. I think it might be
> useful to figure out exactly what anyone is likely to want to configure in
> this way. I suspect that it's going to turn out to be the connections to
> the edges of the system, such as host name/ ip and ports, and db locations.
> Maybe we should think about configuring those separately in e.g a properties
> file or something.
> >
> >
> > thanks
> > david jencks
> >
> >
> >
> >
> >
> > On Jan 18, 2007, at 3:15 PM, Ted Kirby wrote:
> >
> >
> > The idea is allow an identical configuration on a set of machines, yet
> allow customization through property substitution with command line/system
> property override ( i.e. java -Dxxx.yyy.zzz=ABC).
> >
> >
> > For example, allow the following in config.xml:
> >
> > <module name="...">
> > <gbean name="TomcatConnector">
> > <attribute name="port">${ tomcat.port}</attribute>
> > <attribute name="host">${tomcat.listen.ip}</attribute>
> > </gbean>
> > </module>
> >
> >
> > These variables are set on server startup via:
> > java –Dtomcat.port=9090 –Dtomcat.listen.ip= 10.0.0.7
> >
> >
> > JBoss has this capability, and I'd like to bring it to Geronimo.
> >
> >
> > I have opened JIRA 2735 (
> https://issues.apache.org/jira/browse/GERONIMO-2735 ) for
> the feature, but I wanted to solicit community input and feedback on
> features and implementation.
> >
> >
> > I think this feature could be pretty easily implemented in GBeanOverride .
> The constructor reads the values from config.xml. The values could be
> parsed for ${…} constructs. If a known substitution variable is found
> inside, the attribute and its unsubstituted value could be saved in an
> unsubstitutedAttribute hashmap. The attribute hashmap would contain the
> substituted value. This logic can also be applied to the setAttribute
> method. The writeXML method is used to write out the config.xml. As it is
> processing the attributes hashmap, if the attribute name was found in the
> new unsubstitutedAttribute hashmap, write out its value instead.
> >
> >
> > Thoughts?
> >
>
>
Re: Proposal for property substitution in config.xml
Posted by Ted Kirby <te...@gmail.com>.
A properties file sounds like a good idea. Presumably this would work like
how the config.xml filename is passed in: from the configFile attribute of
the AttributeManager GBean in the j2ee-system module, although it may be
overridden by the org.apache.geronimo.config.file system property. The
LocalAttributeManager constructor would then read in the properties file,
setting up a hashmap for substitution variables and their values.
It seems there are three possibilities for value sources: system properties,
environment variables and the properties file. We should develop a
hierarchal search order for them, which is probably how I listed them. We
might add a syntax for specifying the source, although the hierarchy is
probably better.
On 1/18/07, David Jencks <da...@yahoo.com> wrote:
>
> This seems reasonable and I think it will work but I'm worried about an
> infinite regress of configuration systems. Config.xml was supposed to be
> this handy way to substitute attribute values for the "correct" ones
> provided in the module plans. Now we're considering overriding these on the
> command line, and perhaps next we'll be able to specify property files and
> additional xml files to further customize the configuration not to mention
> files containing lists of other configuration override files.. Imagining
> this is making me a little worried. I wonder if a different approach could
> possibly work better, but I sure don't know what it is. I think it might be
> useful to figure out exactly what anyone is likely to want to configure in
> this way. I suspect that it's going to turn out to be the connections to
> the edges of the system, such as host name/ ip and ports, and db locations.
> Maybe we should think about configuring those separately in e.g a
> properties file or something.
>
> thanks
> david jencks
>
> On Jan 18, 2007, at 3:15 PM, Ted Kirby wrote:
>
> The idea is allow an identical configuration on a set of machines, yet
> allow customization through property substitution with command line/system
> property override ( i.e. java -Dxxx.yyy.zzz=ABC).
>
>
> For example, allow the following in config.xml:
>
> <module name="...">
> <gbean name="TomcatConnector">
> <attribute name="port">${tomcat.port}</attribute>
> <attribute name="host">${tomcat.listen.ip}</attribute>
> </gbean>
> </module>
>
>
> These variables are set on server startup via:
> java –Dtomcat.port=9090 –Dtomcat.listen.ip=10.0.0.7
>
>
> JBoss has this capability, and I'd like to bring it to Geronimo.
>
>
> I have opened JIRA 2735 (https://issues.apache.org/jira/browse/GERONIMO-2735
> ) for the feature, but I wanted to solicit community input and feedback on
> features and implementation.
>
>
> I think this feature could be pretty easily implemented in GBeanOverride.
> The constructor reads the values from config.xml. The values could be
> parsed for ${…} constructs. If a known substitution variable is found
> inside, the attribute and its unsubstituted value could be saved in an
> unsubstitutedAttribute hashmap. The attribute hashmap would contain the
> substituted value. This logic can also be applied to the setAttribute
> method. The writeXML method is used to write out the config.xml. As it
> is processing the attributes hashmap, if the attribute name was found in the
> new unsubstitutedAttribute hashmap, write out its value instead.
>
>
> Thoughts?
>
>
>
>
Re: Proposal for property substitution in config.xml
Posted by David Jencks <da...@yahoo.com>.
This seems reasonable and I think it will work but I'm worried about
an infinite regress of configuration systems. Config.xml was
supposed to be this handy way to substitute attribute values for the
"correct" ones provided in the module plans. Now we're considering
overriding these on the command line, and perhaps next we'll be able
to specify property files and additional xml files to further
customize the configuration not to mention files containing lists of
other configuration override files.. Imagining this is making me a
little worried. I wonder if a different approach could possibly work
better, but I sure don't know what it is. I think it might be useful
to figure out exactly what anyone is likely to want to configure in
this way. I suspect that it's going to turn out to be the
connections to the edges of the system, such as host name/ ip and
ports, and db locations. Maybe we should think about configuring
those separately in e.g a properties file or something.
thanks
david jencks
On Jan 18, 2007, at 3:15 PM, Ted Kirby wrote:
> The idea is allow an identical configuration on a set of machines,
> yet allow customization through property substitution with command
> line/system property override ( i.e. java -Dxxx.yyy.zzz=ABC).
>
> For example, allow the following in config.xml:
>
> <module name="...">
> <gbean name="TomcatConnector">
> <attribute name="port">${tomcat.port}</attribute>
> <attribute name="host">${tomcat.listen.ip}</attribute>
> </gbean>
> </module>
>
> These variables are set on server startup via:
> java –Dtomcat.port=9090 –Dtomcat.listen.ip=10.0.0.7
>
> JBoss has this capability, and I'd like to bring it to Geronimo.
>
> I have opened JIRA 2735 (https://issues.apache.org/jira/browse/
> GERONIMO-2735 ) for the feature, but I wanted to solicit community
> input and feedback on features and implementation.
>
> I think this feature could be pretty easily implemented in
> GBeanOverride. The constructor reads the values from config.xml.
> The values could be parsed for ${…} constructs. If a known
> substitution variable is found inside, the attribute and its
> unsubstituted value could be saved in an unsubstitutedAttribute
> hashmap. The attribute hashmap would contain the substituted
> value. This logic can also be applied to the setAttribute method.
> The writeXML method is used to write out the config.xml. As it is
> processing the attributes hashmap, if the attribute name was found
> in the new unsubstitutedAttribute hashmap, write out its value
> instead.
>
> Thoughts?