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]
