I would probably not open a bug if I could find an SLF4J discussion group which SLF4J scholars would read. But at the very least I can consider that there is a documentation bug which could be harmful.

In your documentation you recommend to use Class name of the application class as the name of the actual logger.

Logger logger = LoggerFactory.getLogger(HelloWorld.class);

While this is a good recommendation for a family of HelloWorld projects, this can be quite detrimental for business software.

To be more specific - using class names as logger names is good ONLY when programmers are main users of the code they are themselves writing. For a business application, wherever log readers are not developers of the software that produced the log, naming loggers is a challenging and non-trivial issue. SLF4J's recommendation to use class names simply give business programmers a license for architectural neglect.

I am currently leading refactoring of the Logging mechanism for a big software product developed by 200+ developers (insurance industry), and weeding out those cryptic logger names is quite a challenge.

Probably a better strategy would be to refer to the product architecture and name loggers by components, subcomponents, etc. Like, Billing, Billing.Automatic, Billing.Recurrent, Claim.Filing, General.Mailing, Platform.WebServices.Request, etc. In other words, whatever is the product, define its components and subcomponents and use those hierarchical names so loggers would clearly indicate what part of the product each logger message belongs to.

I am trying to convince developers that their loggers need to be named after the business entity they are working with, not their implementation class. Because slf4j.org represent an authority in logging matters, I have to enforce the rule that disallows your recommendation. This is unfortunate.

If you agree with some of my arguments, I can volunteer to reformulate the paragraphs in your doc so they don't invalidate your recommendations but instead offers various alternatives wherever other strategies are needed.

Sincerely,
Irv Rabin