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