The goal should be to ensure getLogger() doesn't cause a fault (check for null and use a default logger name such as 'unresolved.logger'), and that the javadoc for this method would clearly explain that this method may return the 'default' logger name or an unexpected name because of the stack trace parsing.
The rationale for providing this method (once it's robust in the face of the odd stack trace) seems very similar to why we support LocationInfo=true on appenders or provide line/file, etc conversion patterns in PatternLayout. Scott Deboy COMOTIV SYSTEMS 111 SW Columbia Street Ste. 950 Portland, OR 97201 Telephone: 503.224.7496 Cell: 503.997.1367 Fax: 503.222.0185 [EMAIL PROTECTED] www.comotivsystems.com -----Original Message----- From: Ceki Gülcü [mailto:[EMAIL PROTECTED] Sent: Wed 4/12/2006 8:50 AM To: Log4J Users List Subject: Re: No-args Logger.getLogger() At 05:42 PM 4/12/2006, you wrote: >Why was parsing a stack trace felt to be unsafe? Quoting from [1]: 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. [1] http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Throwable.html#getStackTrace() -- Ceki Gülcü The complete log4j manual: http://www.qos.ch/log4j/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
