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?
>
> 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]
