I tried this idea out and it looked like it worked fine, but I thought I'd propose it here first before making any changes. There are a couple methods in LogManager that take a Class instead of a String for the logger name. I think that the provided class's ClassLoader should be passed along in the appropriate parameters from there and not just ignored. That way, when the ClassLoaderContextSelector is invoked, it will have a ClassLoader provided to it already and can determine the appropriate LoggerContext without having to use reflection.
Now I'd probably want to write a microbenchmark first before really considering this idea, but it's not very complicated. However, this is really only invoked once per class approximately (provided you store the Logger as a static field), and if for some reason the user uses a Class that isn't using in the same ClassLoader as the calling Class, then it might cause weird issues. Then again, I might expect as a user that calling LogManager.getLogger(String.class), for instance, would give me the same Logger no matter what ClassLoader was used provided it's all on the same JVM. Thoughts? P.S. I was playing with the microbenchmarks last night and found this to be really awesome! I'm going to add some other benchmarks and migrate the remaining unit tests we have that are purely for benchmarking purposes into the log4j-perf module. There's no need to run performance tests in our unit tests when they don't even verify anything about the output! -- Matt Sicker <[email protected]>
