Quoting Peter Donald <[EMAIL PROTECTED]>:
> On Mon, 13 Aug 2001 16:24, Giacomo Pati wrote:
> > Quoting Peter Donald <[EMAIL PROTECTED]>:
> > > On Mon, 13 Aug 2001 07:15, giacomo wrote:
> > > > Another think I need to know:
> > > >
> > > > A Logger is defined by its Category, Targets and Priority.
> > >
> > > I would say that a Logger is define by it's Hierarchy and it's
> category,
> > > much
> > > like a Class object is defined by it's ClassLoader and name.
> >
> > Ok, I know you can have separate logging hierarchies which all starts
> with
> > a Category of "" (rootLogger) but how does this relate to the LogKit
> > Configurator. I think we haven't specified having different
> hierarchies,
> > only categories, right?
>
> yup. I think that each Configurator should only configure one Hierarchy.
>
> Maybe we could provide the Hierarchy to the Configurator via a
> setHierarchy()
> method or something.
>
> > Do we have the need configuring different Hierarchies like
> >
> > <hierarchies>
> > <hierarchy name="foo"/>
> > <hierarchy name="bar"/>
> > </hierarchies>
> > <targets>
> > <target .../>
> > </targets>
> > <categories>
> > <category name="..." ... hierarchy="foo"/>
> > </categories>
>
> We could do that but I can not see any tangible benefit at this stage
> for
> doing something like that. Not sure really. Can you think of a reason
> why we
> would want configure multiple hierarchies from one configuration file?
No, I haven't had the need for different Hierarchies in a app yet. Did any
of you?
Giacomo
>
> >
> > Giacomo
> >
> > > > These three
> > > > things cannot be changed for a given Logger, right? Well, I know
> that
> > > > there are methods to change the Targets as well as the Priority
> for a
> > >
> > > given
> > >
> > > > Category but it makes no sense IIRC to have two Components which
> will
> > >
> > > have
> > >
> > > > the same Logger which differ in one of the aspects mentioned above
> > > > (Category, Target, Priority).
> > >
> > > yep. As soon as you change target or priority it changes
> target/priority
> > > for
> > > all components using that logger.
> > >
> > > > BTW: After browsing through the code for several month now (mainly
> > > > logkit and framework/excalibur) I have the feeling that specifying
> > > > everything possible as final (classes, member variables, method
> > > > arguments, local variables, and even catched exceptions) is good
> > > > programming practice, is it?
> > >
> > > Not sure - I have never seen any research on it. It is great when
> > > teaching
> > > students at introductory level because it encourages understanding.
> It
> > > can
> > > also be useful for some compilers/JITs as instead of recycling
> variables
> > > you
> > > create new variables (and make them final) which is easier for
> compilers
> > > to
> > > optimize. The other advantage is that it is *sometimes* easier to
> read
> > > as you
> > > don't have to search through code to verify that value hasn't
> changed.
> > >
> > > So I guess I think it is better but I don't know of any real proof
> ;)
> > >
> > > Cheers,
> > >
> > > Pete
> > >
> > > *-----------------------------------------------------*
> > >
> > > | "Faced with the choice between changing one's mind, |
> > > | and proving that there is no need to do so - almost |
> > > | everyone gets busy on the proof." |
> > > | - John Kenneth Galbraith |
> > >
> > > *-----------------------------------------------------*
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> --
> Cheers,
>
> Pete
>
> *-----------------------------------------------------*
> | "Faced with the choice between changing one's mind, |
> | and proving that there is no need to do so - almost |
> | everyone gets busy on the proof." |
> | - John Kenneth Galbraith |
> *-----------------------------------------------------*
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
