StaticHierarchy class?

["Klein, Scott @ TW" <sc...@L-3com.com>]

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).

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).

Any thoughts or comments on if/why/how this might accomplished?


thanks
s

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>