You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Daniel Serodio <ds...@pucsp.br> on 2006/04/26 19:58:18 UTC

"Safe" version of No-args Logger.getLogger()

Sorry to rehash this subject, but apparently my previous post didn't
make it.

Euxx suggested a "safe" approach to discover the calling class:

public class ClassLocator extends SecurityManager {
  public static Class getCallerClass() {
    return new ClassLocator().getClassContext()[2];
  }
}

Quoting from [1]:

protected Class[] getClassContext()

Returns the current execution stack as an array of classes.

The length of the array is the number of methods on the execution stack.
The element at index 0 is the class of the currently executing method,
the element at index 1 is the class of that method's caller, and so on.

[1]
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/SecurityManager.html#getClassContext()


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Re: "Safe" version of No-args Logger.getLogger()

Posted by Daniel Serodio <ds...@pucsp.br>.
Curt Arnold wrote:
> On Apr 26, 2006, at 12:58 PM, Daniel Serodio wrote:
> 
>> Sorry to rehash this subject, but apparently my previous post didn't
>> make it.
>>
>> Euxx suggested a "safe" approach to discover the calling class:
>>
>> public class ClassLocator extends SecurityManager {
>>   public static Class getCallerClass() {
>>     return new ClassLocator().getClassContext()[2];
>>   }
>> }
>>
>> Quoting from [1]:
>>
>> protected Class[] getClassContext()
>>
>> Returns the current execution stack as an array of classes.
>>
>> The length of the array is the number of methods on the execution stack.
>> The element at index 0 is the class of the currently executing method,
>> the element at index 1 is the class of that method's caller, and so on.
>>
>> [1]
>> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/SecurityManager.html#getClassContext()
> 
> I'd be reluctant to add Logger.getLogger() regardless of the safety code
> used to determine the calling location.  It masks the substantial amount
> of additional complexity necessary to introspect to determine the
> current calling location and only offers a tiny benefit in source code
> reduction.  Having one variant of a method take substantially longer
> than another introduces an undesirable "surprise" that can catch
> developers.

My intention is not to reduce code, but to avoid a subtle kind of "bug"
introduced when (Jr.) developers copy parts of one class when creating
another one, so the "pasted" class has the same Logger as the "copied
from" class.

> Also, it tends to reinforce the notion that logger name must equal class
> name which pops up when people try to create a new Level to do what
> logger name is intended to do.
> 
> I would not be opposed to putting something in the sandbox that
> implements a class factory using the approach, something like:
> 
> public class ClassLogger {
>      private ClassLogger() {
>      }
> 
>     public static Logger getLogger() {
>         ...
>     }
> }
> 
> Then if you really wanted to do the zero-arg getLogger, your code would
> look something like:
> 
> class MyApp {
>       Logger logger = ClassLogger.getLogger();
> 
> }

Nice point. I guess your suggestion works better than mine.

Daniel Serodio


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Re: "Safe" version of No-args Logger.getLogger()

Posted by Curt Arnold <ca...@apache.org>.
On Apr 26, 2006, at 12:58 PM, Daniel Serodio wrote:

> Sorry to rehash this subject, but apparently my previous post didn't
> make it.
>
> Euxx suggested a "safe" approach to discover the calling class:
>
> public class ClassLocator extends SecurityManager {
>   public static Class getCallerClass() {
>     return new ClassLocator().getClassContext()[2];
>   }
> }
>
> Quoting from [1]:
>
> protected Class[] getClassContext()
>
> Returns the current execution stack as an array of classes.
>
> The length of the array is the number of methods on the execution  
> stack.
> The element at index 0 is the class of the currently executing method,
> the element at index 1 is the class of that method's caller, and so  
> on.
>
> [1]
> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/ 
> SecurityManager.html#getClassContext()
>

I'd be reluctant to add Logger.getLogger() regardless of the safety  
code used to determine the calling location.  It masks the  
substantial amount of additional complexity necessary to introspect  
to determine the current calling location and only offers a tiny  
benefit in source code reduction.  Having one variant of a method  
take substantially longer than another introduces an undesirable  
"surprise" that can catch developers.

Also, it tends to reinforce the notion that logger name must equal  
class name which pops up when people try to create a new Level to do  
what logger name is intended to do.

I would not be opposed to putting something in the sandbox that  
implements a class factory using the approach, something like:

public class ClassLogger {
      private ClassLogger() {
      }

     public static Logger getLogger() {
         ...
     }
}

Then if you really wanted to do the zero-arg getLogger, your code  
would look something like:

class MyApp {
       Logger logger = ClassLogger.getLogger();

}




---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org