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.
Anders
"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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
