Red5 updated its slf4j and logback libraries recently to address security vulnerabilities; in doing so, this broke the old code in Red5 open source logging that allowed the separation of logging into additional contexts such as those used by custom webapps and Red5 Pro cloudstorage. The symptom of which was difficult to catch since it just prevented logging without any indication. Currently, the only work-arounds are to replace the logger libraries with the older versions or replace every use of Red5LoggerFactory with the SLF4J default interface LoggerFactory; the SLF4J factory does not accept a context. Here is an example:
/*
* The recent updates for SLF4J prevents Red5 logger factory use of a context,
* it does not work in the latest Red5 open source libraries. We suggest a
* replacement in the interim.
*/
// previous logger style with context separation
//private static Logger log = Red5LoggerFactory.getLogger(Application.class, "chat");
// newer / work-around version using SLF4J
private static Logger log = LoggerFactory.getLogger(Application.class); Logging in this way requires the implementer to update the default server logback configuration in conf/logback.xml to expose their classes using the logger so they will appear in the logs/red5.log file.