Gary Shea wrote:
>Ok, I can buy this argument. But there are still a few troubling
>details ;) Right now the LogEnabled interface is the "right" place to
>provide the component with a logger. That is great as long as a
>component only requires 'a' (i.e., one) logger.
>
>Your re-phrasing of Shawn's sentence suggests that a container may
>create child loggers, but may not directly use the logs it has created;
>instead it creats new child loggers strictly for the benefits of its
>components. Unless more re-phrasing is called for, that means that a
>container must provide a component with all of the child loggers needed
>by that component. In that case, shouldn't LogEnabled then take a hash
>or set or array or something?
>
I don't think that is what is meant. The component can use the child
loggers it creates.
It can also pass them to components it contains. LogEnabled just passes
the root Logger
for this component.
Perhaps the only issue is what if a component needs to write to 2
different categories
(ie. Loggers). However, this may mean the logging design is too complex,
or the
component is a candidate to be sub-divided.
>
>My guess is that this is not what is intended. How about:
>
>1) The container will create the "root logger relative to the
>[component]", and hand it to the component via enableLogging().
>
>2) If the component needs additional child loggers, it can derive them
>from the logger handed over by the container.
>
>3) There is an implicit assumption that configuration of log priorities
>is a different concern than configuration of the logging heirarchy, and
>where logging heirarchy is under program control, log priorities are
>explicitly NOT under program control. So log priorities may only be set
>in a configuration file (or maybe the command line).
>
>A bit tortured but it works. Seriously in need of being stated
>succinctly in the interface doc!!!
>
> Gary
>
>[2002-02-27 18:35 +0100] Stephen McConnell ([EMAIL PROTECTED]) wrote:
>
>>Shawn Boyce wrote:
>>
>>>So to summarize:
>>>1) a component can create its own child loggers/categories
>>>relative to its "root" logger. Its container does not know or
>>>manage these. A component does not configure its child loggers however.
>>>
>>I think the answer may be Yes!
>>But I'll rephrase what you said.
>>
>> 1. a object is supplied with a logger (which it the
>> root logger relative to the object)
>> 2. that object can create child logger from the suplier
>> logger, and apply these child logger to the components
>> it manages
>> 3. management of logging priority (INFO, DEBUG, ERROR, etc.
>> is not a concern of the object)
>>
>>>2) configuration of all loggers is done at the application level
>>>or framework level
>>>
>> 4. The configuration of the log hierachy is done at a "site"
>> or "framework" level
>>
>>So, yes - I agree :-).
>>
>>*snip*
>>
--
Shawn Boyce
QCOM, Inc.
Quality Software is Our Business
http://www.qcominc.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
