[slf4j-dev] [Bug 163] Copy & paste of LoggerFactory.getLogger

[bugzilla-daemon at pixie.qos.ch]

http://bugzilla.slf4j.org/show_bug.cgi?id=163





--- Comment #29 from Joern Huxhorn <joern at huxhorn.de>  2010-03-30 17:06:57 ---
(In reply to comment #28)
> I suggest you run some performance tests. I am certain you are going to find
> that performance is very bad when logging is disabled as creating a Throwable
> on every call before doing any filtering is astronomically more expensive than
> just using a static string.
> 
> Again, I would suggest using a solution based on annotations. I know someone
> has already done it.
> 

I also like the suggested annotation solution best since it does not have any
downside I'm aware of. Unfortunately, I don't really know how to implement
anything like it.

It's pretty hard to benchmark code like the one in comment #27 without walking
straight into some micro-benchmark trap. Any suggestions?

I'm not sure if something like SimpleLogging above should really be included in
SLF4J (or some extension jar) at all, I was merely playing around and wanted to
share it. (most importantly, this shouldn't be considered a part of my SLF4J
2.0 proposal;))


However, I've just added another method, getCallingLogger(), that's returning
either the logger of the calling class or a NOPLogger if such a logger could
not be resolved (in case of Throwable.getStackTrace() returning an empty
STE[]).

This wouldn't have the likely big performance impact like the rest of the
methods since it would only be called once while initializing the Logger.

The code is again contained in 
http://github.com/huxi/slf4j/blob/slf4j-redesign/slf4j-n-api/src/main/java/org/slf4j/n/SimpleLogging.java
and
http://github.com/huxi/slf4j/blob/slf4j-redesign/slf4j-n-api/src/test/java/org/slf4j/n/SimpleLoggingTest.java

That method isn't really bad, I think.


-- 
Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.