>Logger x1 = Logger.getLogger("x");
>Logger x2 = Logger.getLogger("x");
>
>Both x1 and x2 reference the exact same object.Of course, but you lose the class level granularity for configurations. Which is exactly what I would like to keep, and in order to do so you must create loggers by class. The issue is that if you have a configuration for "com.foo", then request a logger with the class "com.foo.bar.FooBar" a new logger instance is created, rather than using the "com.foo" logger. (just as a side note: the interesting thing here is that it will have a configuration like "com.foo"). >Even if the saving in the memory footprint were important (which they are not!) Why is saving memory not important? Can you give me some insight into how you would configure a system that needs to be able to have each classes logger configurable while also being able to keep the total number of loggers instantiated well below n, where n is the total number of classes loaded in the system (and using Loggers). thanks scott -----Original Message----- From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] Sent: Friday, June 21, 2002 12:40 PM To: Log4J Users List Subject: Re: StaticHierarchy class? At 14:46 19.06.2002 -0700, Klein, Scott @ TW wrote: >I'm full of questions/comments today... > >Has anyone worried about the amount of resources (primarily mem space) >attributed to Log4J to the extent that there was a need for a >"StaticHierarchy" whereby, if a user requests a Logger that does not exist >it will NOT be created. Basically, they have to be listed in the config >file. > >A little strict - but I was thinking a step further where if >com.foo.bar.FooBar asks for a Logger using getLogger( this.getClass() ) >then a non-Null (or non-Root!) logger is returned iff: >+ there is a predefined logger for com.foo.bar.FooBar >OR >+ there is a predefined logger for com, or com.foo, or com.foo.bar - but in >this case the logger returned is NOT a newly instantiated one, but the >corresponding logger to the match as if they had called getLogger( "com.foo" >) for example (if that makes sense). Logger x1 = Logger.getLogger("x"); Logger x2 = Logger.getLogger("x"); Both x1 and x2 reference the exact same object. >Basically, the constraint is that if the class does not have a logger >defined for it, or the class is contained in a package that does not have a >logger defined for it, or its super-packages, then the root logger is >returned. Otherwise, the deepest logger in the hierarchy along the path to >the requestor is returned. You lose flexibility (you can't have people >making changes to the Logger they get), but you save resources. > >Not sure if all that makes sense, but my primary concern is if I have 100 >classes that ask: Logger.getLogger(this.getClass()) then I am going to be >carrying 100 instances of Logger around (guaranteed). Even if all your 100 classes used the root logger the gains in the memory footprint would be negligible compared to the memory foot print of your 100 classes. Even if the saving in the memory footprint were important (which they are not!) the list of configured loggers can change during the execution of the program but an already assigned logger cannot shed its skin and automatically assume another identity. >Any thoughts or comments on if/why/how this might accomplished? Yes, one comment: don't tune what you don't need to tune. Here is one of my favorite quotes: Have lots of ideas and throw away the bad ones. You aren't going to have good ideas unless you have lots of ideas and some sort of principle of selection. -- Linus Pauling (the only person to win two unshared Nobel Prizes) >thanks >s -- Ceki -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
