commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Bateman (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LOGGING-137) LogFactory.getLog()
Date Wed, 18 Aug 2010 20:25:16 GMT

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


Mime
View raw message