Get rid of per-instance logger creation [SPR-9747]

[spring-projects-issues]

Patrick Linskey opened SPR-9747 and commented

The per-instance lookup turns into a call to Class.getClassLoader0() for every HandlerMethod created (which is a per-request proceeding). This patch avoids that while still maintaining compilation-level backward-compatibility. Note that this patch does change the logging semantics a bit -- third-party subclasses that use the logger will start to see their messages in the HandlerMethod namespace, and the InvocableHandlerMethod and ServletInvocableHandlerMethod log statements will be separated into their own distinct channels now. If this is a design choice, it would be possible to still avoid the slow call while preserving the logging behavior by implementing a little class => logger ConcurrentHashMap in HandlerMethod -- this should be a small cache, as it's not expected that there will be many subclasses.

---

Affects: 3.1.1, 3.1.2, 3.2 M2

Referenced from: commits 0a877af, 2295372

[spring-projects-issues]

Patrick Linskey commented

GitHub commit for 3.1.1: pcl@124a16d
GitHub commit for master: pcl@154d4a9

Note that this and #14382 both contain edits to HandlerMethod. The GitHub commit linked to in #14382 is applied on top of this commit; applying them out-of-order might take some manual tweaking.

'./gradlew build' succeeds with this patch on master. I'm still trying to figure out how to get 3.1.1 to build on my machine (http://forum.springsource.org/showthread.php?129846-Spring-3-1-1-compilation&p=423733#post423733)

[spring-projects-issues]

Patrick Linskey commented

FYI, this eliminates 3.5% of the CPU burn in my Spring-MVC app.

[spring-projects-issues]

Rossen Stoyanchev commented

I've opted for a fixed logger category based on the name of the HandlerMethod class.