The current implementation(1.7.5) of slf4j's Log4jLoggerFactory caches log4j Logger instances in a singleton using a map keyed by Logger name. This caching will prevent the discovery of additional Logger instances that happen to have the same name, but reside in a different Repository (which LogManager.getLogger() would have selected if the cache was not used, since getLogger() uses RepositorySelector first, then looks up the logger by name from the returned repository.
This behavior causes custom implementations of RepositorySelector in log4j to appear as if they are not working properly, sending output configured for one Logger in Repository 2 to a different Logger configured in Repository 1 when Loggers in both repositories have the same name (like "org.springframework"). An alternative that appears to solve the problem of caching Loggers only by name is to calculate the key by name+LogManager.getLoggerRepository(). This has the effect of caching Loggers using both the name and the Repository, effectivly preventing the problem of missing loggers when using custom repository selectors. Has anyone else had this problem/solution? I saw bug entry #43, but the solution there focused on logBack, rather than the map key in slf4j's implementation of Log4jLoggerFactory.
_______________________________________________ slf4j-user mailing list [email protected] http://mailman.qos.ch/mailman/listinfo/slf4j-user
