[
https://issues.apache.org/jira/browse/LOGGING-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12896439#action_12896439
]
Sebb commented on LOGGING-137:
------------------------------
The patch file contains a spurious update to svn:ignore.
The .java files appear to duplicate the content of the patch files.
Also, the static fields in CallStackUtil need to be final, apart from
isAtLeastJava14 which needs to be volatile for safe publication across threads.
It would be useful to use Thread.getStackTrace() if available, as that is
likely to be quicker.
The Javadoc needs to document that the returned classname can be null.
What happens to the logger in this case?
It's not immediately obvious why the getCallerJava14 method needs to scan the
stack trace twice.
Surely one can just add a fixed offset to the depth to find the caller stack
frame?
Also, Commons generally does not use @author tags, as ASF code is a
collaborative effort.
Attribution can be added to the <contributors> section of the POM instead,
and/or release notes.
> 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: CallStack.patch, CallStackTest.java, CallStackUtil.java,
> 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.
