[
https://issues.apache.org/jira/browse/LOGGING-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12900017#action_12900017
]
Doug Bateman commented on LOGGING-137:
--------------------------------------
The other concern I have that even the Java 1.4 approach of using
Throwable.getStackTrace() may have variations across JVMs. Hence I feel it's
better to calculate once rather than assume a hard coded constant.
Specifically, the Java 1.4.2 JavaDoc for Throwable.getStackTrace() reads:
"Some virtual machines may, under some circumstances, omit one or more
stack frames from the stack trace. In the extreme case, a virtual machine that
has no stack trace information concerning this throwable is permitted to return
a zero-length array from this method. Generally speaking, the array returned by
this method will contain one element for every frame that would be printed by
printStackTrace. "
And even Throwable.fillInStackTrace() doesn't specify what is considered the
top of the call stack. It only takes one JVM vendor to do things differently
to throw a wrench in the works. For example, a JVM vendor might include
Throwable.fillInStackTrace() itself in the call stack returned, even though the
Sun JRE does not.
This is why I prefer the approach of actually calculating it once in a static
initializer. It avoids the issue. However, we could do the simple approach by
waiting to see if it becomes a reported issue before introducing added
complexity. And developers encountering problems can always revert to using
the Logger.getLogger(name) approach.
> LogFactory.getLog()
> -------------------
>
> Key: LOGGING-137
> URL: https://issues.apache.org/jira/browse/LOGGING-137
> Project: Commons Logging
> Issue Type: New Feature
> Affects Versions: 1.1.2
> Reporter: Doug Bateman
> Attachments: CallStackTestCase.java, CallStackUtil.java.0,
> CallStackUtil.java.1, CallStackUtil.java.2, LogFactory.java
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> Presently, in Apache Commons, the most common way to get a logger is to do
> something like:
> public class MyClass {
> private static Log log = LogFactory.getLog(MyClass.class);
> }
> Notice how MyClass.class (or alternatively a string name) is passed as a
> parameter. The annoying aspect of this is that sometimes the class name
> doesn't get updated when doing copy/paste operations. A desirable
> alternative might be:
> public class MyClass {
> private static Log log = LogFactory.getLog(); //class name inferred from
> call stack
> }
> With such an approach there are two possible concerns I can foresee:
> * Call stack inspection isn't terribly fast. However since Loggers are
> generally initialized only once, when the class is first loaded, performance
> isn't likely to be a major problem.
> * Commons-logging is Java 1.1 compatible. Thus care must be taken to
> ensure compatibility isn't broken.
> * Commons-logging doesn't depend on commons-lang, and thus the utilities
> in commons-lang cannot be used.
> In Java 1.4, the call stack is easily obtained using Thread.getCallStack().
> Prior to Java 1.4, the only way to obtain the call stack is to inspect the
> stack trace of an exception.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
