logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anders Kristensen <akristen...@dynamicsoft.com>
Subject Re: FW: Log4J questions
Date Tue, 26 Jun 2001 21:58:20 GMT
See the log4j javadoc documentation for the PatternLayout %M and %C
conversion characters. They're implemented in the same manner as in the
JSR 47 framework -- both extract info from a call stack obtained from a
rendered exception. This is not reliable -- stack trace layout is not
standardized and JVM's are free to perform various optimizations, e.g.
inlining, which remove stack frames completely.

I don't think we want a Category constructor which depends on something
which is inherently unreliable, so you can probably forget about such a
no-arg constructor. BTW, this can't be a constructor anyway because
log4j has to guarantee that an existing Category is returned if one
existed with that name. It can do that in a static getInstance method
but not in a ctor.


"Adam L. Menkes" wrote:
> Though Sun's JDK 1.4 logging is bad compared to what Log4J appears
> capable of doing, there are some things that I saw that I liked, but
> could not figure out how to do in Log4J.
> Specifically, the logging of class/method names without having to
> provide them. For example, in JDK 1.4 beta, you can do the following:
> logger.config("Some message");
> And it will provide the following info (I added the color for
> emphasis):
> Jun 26, 2001 12:52:11 PM LogTest <init>
> INFO: Some message
> As you can see, it picks up the class name and method (in this case,
> the constructor, represented by "<init>").
> Note that .config is only used for example, as normally you would use
> logger.entering() / logger.exiting() (see bug ID #4474150).
> This is very useful, since class names may change (though infrequent)
> and method names change (more frequent), plus, it allows for
> copy/paste of standard calls to every method:
> logger.entering();
> ...
> logger.exiting();
> Also, if a class inherits from another class, it would be nice if it
> reported the actual class ("entering Apple" instead of the superclass
> "entering Fruit") without having to account for the differences.
> Similarly, it would be nice if Category.getInstance() could add a
> no-arg constructor which would determine the class without having to
> add "MyClass.class" or "MyClass.class.getName()". I would make it
> additional, and not deprecate the existing, as you may want to setup
> global (public static) Category in a separate class.
> ---------
> On another note, just FYI, there are some typos in your documentation.
> In examples (and examples/doc-files), the *.lcf files spell
> "documentation" incorrectly (documenation).

To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org

View raw message