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