Do users expect their log4j2 configurations to be picked up and used to
configure a log manager? Or do they just want to use the log4j2 API and
have the logging subsystem be the spot where the configuration is kept
It's been requested for some time to have log4j2 support in WildFly .
About a month ago I was finally able to start looking into this.
In log4j2  they "separated" the API from the implementation to make it
"clear for application developers which classes and methods they can use
while ensuring forward compatibility". However API has no configuration
options. It's essentially like a logging facade which requires log4j-core
 if you want appenders, layouts, etc.
While it was pretty easy to implement just the API , I'm not sure this
is what users are looking for. Implementing the API will allow you to use
log4j2 loggers which just delegate to JBoss Log Manager. However none of
the log4j2 appenders, async logging or log4j2 configurations could be used.
This would require log4j-core .
If users expect their log4j2 configuration files within their deployment to
configure a log4j2 LogManager we run into problems, since this would
require log4j-core to work. The simple solution seemed to be if they want
that to work they just need to include log4j-core in their deployment.
However in the awesomeness that is log4j2 (where's a SarcMark TM when you
need it?) parts of log4j-core seem to require a
org.apache.logging.log4j.core.LoggerContext instead of the LoggerContext
from the API. This means we can't simply just use our own LoggerContext
implementation and just delegate to the log4j-core embedded in the
I guess that got into a little too much detail there :) The real question
is do we want to support user defined log4j2 configurations? If so it may
get a bit tricky getting this to work. If not we can easily support just
delegating the log4j2 loggers to JBoss Log Manager loggers.
Any feedback is appreciated. Especially if you're familiar with log4j2 and
have opinions on how it should work with WildFly.
James R. Perkins
JBoss by Red Hat