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 deployment.
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.