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?
