WildFly 18 -> 31 Upgrade: Logging Subsystem Not Logging

[Bryan Mulkey]

We are finishing up our upgrade from WildFly 18 to 31.0.1. Our logging subsystem configuration is pretty straightforward. We only had to remove one custom appender with a class that extended log4j 1.x's FileAppender. We commented that out and have no problems. We now have it running in a custom module (com.mycompany.app) which has its own log4jx.ml with a dependency on ch.qos.reload4j, and that works fine.

However we have several periodic-size-rotating-file-handlers configured. Here's an example of one:

<periodic-size-rotating-file-handler name="KAFKA" autoflush="true">
                <filter-spec value="accept"/>
                <formatter>
                    <named-formatter name="PATTERN-KAFKA"/>
                </formatter>
                <file path="/opt/app/logs/kafka.log"/>
                <suffix value=".yyyy-MM-dd"/>
                <append value="true"/>
                <rotate-size value="500M"/>
                <max-backup-index value="10"/>

</periodic-size-rotating-file-handler>

And we have a logger element configured:

 <logger category="com.mycompany.app.kafka" use-parent-handlers="false">
                <level name="INFO"/>
                <handlers>
                    <handler name="KAFKA"/>
                </handlers>
 </logger
And the formatter:

<formatter name="PATTERN-KAFKA">
                <pattern-formatter pattern="%d %-5p [%c] [%X{session}:%X{user}@%X{tenant}] (%t) %m%n"/>
</formatter>

Once our app deploys, kafka.log will get created, but nothing will ever be written to it. Same for all the other periodic-size-rotating-file-handers that we have in our subsystem.

We also have had <use-deployment-logging-config value="true"/> set in standalone.xml in WildFly 18 and have kept it the same now.

If I set "use-deployment-logging-config" to false, and remove custom logging config from the code in the module, still nothing is logged. 

The code that is not logging to the periodic-rotating-file-handlers is in its own custom modules, com.mycompany.app.kafka, com.mycompany.app.subsys, com.mycompany.app.subsys2, etc. The internal logger classes use in there depends on log4j 1.x and always has. Just not sure how "allergic" the latest logging subsystem is to log4j 1.x. 

I'm at a loss as to what to do next. Is there a way to debug the logging system, or anyone see anything wrong with the little bit of info/config I've shared? 

[James Perkins]

Support for log4 j1.x was removed from WildFly as the log4j 1.x itself reached end of life 9 years ago.

You can still use log4j 1.x if you would like, but the logging subsystem will not directly support it. I'm a little confused on why you're using a log4j.xml configuration and attempting to use the logging subsystem for configuration.

One option is to use the https://github.com/jboss-logging/log4j-jboss-logmanager. This project is also being deprecated, but it does replace the log4j log manager and delegate to the JBoss Log Manager which WildFly uses.

[Bryan Mulkey]

Thank you, James. Our project is a large, several million LOC behemoth that's been evolving for 20+ years. It has lots of "bandaids," hence the log4j.xml thrown in there.

I was able to fix the issue this afternoon by updating my code to use log4j2-api and have a dependency on the provided/public org.apache.logging.log4j.api module. 

[James Perkins]

Ah yes, using log4j2 would work as well. There is integration in WildFly for the log4j 2 API.