[ https://issues.redhat.com/browse/WFCORE-482?page=com.atlassian.jira.plugi... ] Boris Unckel edited comment on WFCORE-482 at 3/21/20 5:34 AM: -------------------------------------------------------------- Our usecase of logging facades (slf4j, commons-logging, jboss-logging) and log-apis (jul, jboss-logmanager, log4j2-api) or log-adapters (log4j-jboss-logmanager, log4j2-jboss-logmanager) is to provide the binaries by the server and to remove them from the application. We use logging profiles to have application specific logs (great feature!). The major reason behind is to have a single point of control on the server side. With CLI we have the ability to control all of mentioned loggers at a central place at runtime, without deployments, without restarts, without file change. We have integrated log4j2-api as module and backported log4j2-jboss-logmanager to an older WildFly 12. It is integrated in the same way as the other log APIs and provisioned as implicit module dependency. I understand that people want to utilize log4j-impl, and they can control this [http://docs.wildfly.org/19/Admin_Guide.html#logging-attributes] add-logging-api-dependencies and provision the jar in the application. The default WildFly server should have a single behaviour for deployed applications - log direct and indirect through jboss-logmanager, which is the current default with implicit dependencies. was (Author: xf01213): Our usecase of logging facades (slf4j, commons-logging, jboss-logging) and log-apis (jul, jboss-logmanager, log4j2-api) or log-adapters (log4j-jboss-logmanager, log4j2-jboss-logmanager) is to provide the binaries by the server and to remove them from the application. We use logging profiles to have application specific logs (great feature!). The major reason behind is to have a single point of control on the server side. With CLI we have the ability to control all of mentioned loggers at a central place at runtime, without deployments, without restarts, without file change. We have integrated log4j2-api as module and backported log4j2-jboss-logmanager to an older WildFly 12. It is integrated in the same way as the other log APIs and provisioned as implicit module dependency. I understand that people want to utilize log4j-impl, and they can control this [http://docs.wildfly.org/19/Admin_Guide.html#logging-attributes|add-loggin...] and provision the jar in the application. The default WildFly server should have a single behaviour for deployed applications - log direct and indirect through jboss-logmanager, which is the current default with implicit dependencies. -- This message was sent by Atlassian Jira (v7.13.8#713008)