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]
