[PEAK] peak logs
Phillip J. Eby
pje at telecommunity.com
Fri Jan 2 14:51:34 EST 2004
At 12:40 PM 1/2/04 -0800, darryl wrote:
>darryl at hydra jabberbot $ peak runIni test.ini
><peak.running.logs.LogStream object at 0x83d8324>
>30
>
>-----------------------------------------------------------------
>What am i doing wrong ?
Well, as it turns out, you're getting the parent's log just fine. It's
just that the parent's logger isn't coming from the right place, on account
of being defined at a different configuration level than the logging
service. Adding these two lines:
[Component Factories]
peak.running.logs.ILoggingService = logs.DefaultLoggingService
to the configuration fixed it for me.
This is a bit of a problem, in that I'm more and more often finding that
factory-built services are often "global" when they need to be more
"local". The issue is that services only know about configuration that
exists at their level or *higher* in the component hierarchy. But
application configuration like executable '.ini' files are loaded *lower*
in the hierarchy than the global service definitions.
Other folks have been bitten by this problem a couple of times, myself
included. That seems a pretty good sign that something needs to be done
about it, especially since we are moving towards *more* service components,
not fewer ones.
In theory, we might instantiate a new service instance whenever the
requesting component has a different configuration for anything the service
depends on. (For example, property settings under 'peak.logs' in the
current case.) Or, we could raise an error when you try to look up the
service component, telling you that the service you're using isn't
configured the way you think it is.
Unfortunately, to do either of those things, we would not only have to know
what all the dependencies of a component *are*, but also the dependencies
of any components it was depending on. That seems unscalable, to say the
least.
It seems a simpler solution would be some way to say "I'd like to have this
component be used as a home for global services." The hard parts are: 1)
which component? and 2) what services?
In practice, most breakage today comes from configuration files loaded into
non-root components, so that would be an obvious place to start on part
1. But part 2 is not nearly as obvious. Some components *want* to stay
global. For example, my hypothetical ZConfig schema service.
I'm going to have to think about this one some more. At least for now,
fixing it is easy when you know what's happening: just add a Component
Factories declaration for the affected services.
More information about the PEAK
mailing list