Configuration and management of Configuration

[Steve Gibson <St...@cowww.com>]

This is a borderline HiveMind user/development question...
 
Our embryonic application uses one big Property file to manage the
configuration of services.
The lazy programmer in me says leave this as a big Property file, wrap a
configuration class around it for passing into services and write a
configuration service that can manage changes to it (we need to be able
to reconfigure parts of this file, preferably putting changes from
default into a second file which is loaded over the top at startup).
 
Having one Property file makes the management easy, but means services
must search for their properties.
If I make a bunch of configuration points, though, the current api does
not allow me to call <module>.getConfigurationIds() or the like.
Thinking out loud, if I had that, I guess I could have services register
for change events on configuration points and even dynamically update
configurations (from the configuration service) without having to do
direct calls to the service(s) that use that configuration point.
 
Sounds a little scary to me, especially as some configuration items are
more like constructor parameters.
 
The other issue I currently have with configuration is this - I develop
and test without building a jar. That means I can only have the one
module descriptor. So all my configuration is mixed in with service
point definitions, etc. I really want to be able to put contributions
into separate configuration files. Maybe I need to look at the
BuilderFactory a little more closely...
 
Steve Gibson
Software Engineer
COWWW Software
 

RE: Configuration and management of Configuration

["Howard M. Lewis Ship" <hl...@comcast.net>]

Didn't quite follow all of that. I would say that, yes, wrap your .properties file as a
SymbolSource.
 
A module can reference a <sub-module>. This allows a single META-INF/hivemodule.sdl  to "bring in"
related modules, which should work well for you.
 
 

--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
http://howardlewisship.com <http://howardlewisship.com/> 


-----Original Message-----
From: Steve Gibson [mailto:Steve.Gibson@cowww.com] 
Sent: Thursday, June 10, 2004 11:54 AM
To: hivemind-dev@jakarta.apache.org
Subject: Configuration and management of Configuration


This is a borderline HiveMind user/development question...
 
Our embryonic application uses one big Property file to manage the configuration of services.
The lazy programmer in me says leave this as a big Property file, wrap a configuration class around
it for passing into services and write a configuration service that can manage changes to it (we
need to be able to reconfigure parts of this file, preferably putting changes from default into a
second file which is loaded over the top at startup).
 
Having one Property file makes the management easy, but means services must search for their
properties.
If I make a bunch of configuration points, though, the current api does not allow me to call
<module>.getConfigurationIds() or the like.
Thinking out loud, if I had that, I guess I could have services register for change events on
configuration points and even dynamically update configurations (from the configuration service)
without having to do direct calls to the service(s) that use that configuration point.
 
Sounds a little scary to me, especially as some configuration items are more like constructor
parameters.
 
The other issue I currently have with configuration is this - I develop and test without building a
jar. That means I can only have the one module descriptor. So all my configuration is mixed in with
service point definitions, etc. I really want to be able to put contributions into separate
configuration files. Maybe I need to look at the BuilderFactory a little more closely...
 
Steve Gibson
Software Engineer
COWWW Software