[PEAK] peak logs

[Phillip J. Eby]

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.