Re: Proposal for property substitution in config.xml
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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?
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
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?
