HttpLogging hard codes the logger name to org.springframework.web, which is wrong.
private static final Log fallbackLogger =
LogFactory.getLog("org.springframework.web." + HttpLogging.class.getSimpleName());
Comment From: sbrannen
In line with the class-level Javadoc, it creates a fallback logger named org.springframework.web.HttpLogging, not org.springframework.web.
So what makes you think something is wrong with that?
Comment From: asarkar
So what makes you think something is wrong with that?
The fact that it logs under a fake package, and makes it hard to find the class if need be. If I go to the package that's shown in the logs, there'd not be a HttpLogging class there. Why not get a logger by passing the class, and let the logging framework take care of the FQN?
Comment From: sbrannen
Hopefully the Javadoc for org.springframework.core.log.LogDelegateFactory.getCompositeLog(Log, Log, Log...) clarifies things for you:
Create a composite logger that delegates to a primary or falls back on a secondary logger if logging for the primary logger is not enabled.
This may be used for fallback logging from lower-level packages that logically should log together with some higher-level package but the two don't happen to share a suitable parent package (e.g. logging for the web and lower-level http and codec packages). For such cases the primary (class-based) logger can be wrapped with a shared fallback logger.
If not, perhaps @rstoyanchev can further explain the rationale for this setup.
Comment From: rstoyanchev
When org.springframework.web is enabled, it covers logging for spring-web, spring-webmvc, and spring-webflux, but it's easy to overlook org.springframewor.http and the codecs from spring-core that are also logically part of web logging. That's the purpose of the fallback logger is to provide basic logging at least from those areas when org.springframework.web is on.
Simply enable org.springframework.http and/or org.springframework.core.codec and you'll get exact class based category logging as usual.