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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
