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
