[PEAK] runIni => ZConfig revisited
alexander smishlajev
alex at ank-sia.com
Fri Nov 14 12:52:50 EST 2003
John Landahl wrote, at 14.11.2003 12:55:
> In re-reading the message at
> <http://www.eby-sarna.com/pipermail/peak/2003-July/000589.html>, and
> with the recently acquired knowledge of config.loadConfigFile(), it
> occurred to me that one could have a key in a ZConfig-based config setup
> a list of extra files for the application to load at startup. Something
> like this (untested):
>
> class MyApp(AbstractCommand):
> configFiles = binding.Make(list)
>
> def __loadConfig(self):
> for file in self.configFiles:
> config.loadConfigFile(self, file)
> __loadConfig = binding.Make(__loadConfig, uponAssembly=True)
>
> The main (ZConfig-based) file might then look like:
>
> Config foo-bar.ini
> Config more-options.ini
>
> Does this seem reasonable?
not for us. thanks for suggestion, anyway.
the problem with keeping two config files (ZConfig and .ini) instead of
one is that two files are twice as difficult to maintain. so we took
the path that Phillip suggested: made a "root" component (not subclass
of config_components.ConfigurationRoot; just a regular component
instantiated by ZConfig schema), registering application-wide services
like this:
# registering our logger as a default logger
_provider = lambda *args: self.logger
self.registerProvider(PropertyName("peak.logs.*"), _provider)
self.registerProvider(interfaces.ILogger, _provider)
(self.logger is set by ZConfig.)
by the way, if anyone interested: we made PEAK-based application, having
several deployments yet, with core functionality now approaching it's
beta stage.
the application serves as an interface to medical laboratory instruments
(analyzers), getting measurement result data from these instruments and
sending work orders to ones that support workorder upload. the
application is run as windows nt service.
unfortunately, we cannot open all of the application sources, but
perhaps we could share some chunks of our code. for example, we would
be happy if our reactor is adopted to PEAK mainline.
we use ZConfig, bindings (of course!), pretty much of 'running' package,
and fmtparse module to decode data from some instruments.
one of the biggest problems for us now is the requirement to restart the
application upon any change in configuration file. we have a strong
need to reload config files on the fly, restarting or updating only
those components that have their configuration changed.
best wishes,
alex.
More information about the PEAK
mailing list