[ https://issues.redhat.com/browse/WFCORE-482?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-482: -------------------------------------- Thanks for the feedback [~marlowa42]. WildFly itself uses jboss-logging as it's logging facade. This is akin to slf4j as it's just a facade so that part shouldn't be an issue. None of WildFly Core or WildFly itself uses log4j. With the minor exception of the logging subsystem, but that is only used to configure a deployment which uses a log4j configuration file. The issue is more with the log manager itself. For the log manager WildFly uses the JBoss Log Manager which is an extension of JUL. Both log4j is a log manager. With log4j2 it's somewhat separated where they have a logging facade, log4j-api, and a log manager implementation. What this JIRA would solve is having a log4j2 API implementation that can write to the jboss-logmanager. What I mean by this is that the reason log4j2 is not currently supported is that there is not log4j-api -> JUL library or log4j-api -> jboss-logmanager library. Currently, at least as far as I know, the only log4j-api implementation is log4j-core which is it's own log manager and you can't really have two log managers being used. I've got a project that does handle this, but I'm experimenting a bit with what could happen when a user does provide log4j-core in their deployment as they may be wanting to use some of the features, like async-loggers, for their deployment. -- This message was sent by Atlassian Jira (v7.13.8#713008)