Custom Log4j2 Appender Not Triggered on CloudHub 2.0 / Runtime Fabric Due to PluginManager Not Loading Application-Packaged Appenders

Symptoms

• A custom Log4j2 appender (a class annotated with @Plugin, packaged in its own JAR with a META-INF/org/apache/logging/log4j/core/config/plugins/Log4j2Plugins.dat descriptor) is referenced in the application's log4j2.xml.
• The appender works correctly when the application runs locally in Anypoint Studio.
• After deploying the same application to CloudHub 2.0 or Runtime Fabric, the appender is never invoked:
  • No log entries reach the custom destination (e.g. Splunk, ELK/Logstash, AWS Kinesis, a custom HTTP/socket target).
  • Nothing from the custom appender appears in the CloudHub 2.0 / Runtime Manager logs.
  • No explicit error is shown. On CloudHub 2.0, Log4j2's own status (StatusLogger) messages are not surfaced, so the failure is silent.
• In some environments or older runtimes a warning similar to the following may appear:

The packages attribute is deprecated. Please use a plugin descriptor file instead 

Note: this warning is not reliably emitted; its absence does not mean the appender is working.

• At application startup, the following message confirms the underlying cause:

[2026-08-02 22:55:43.109] WARN  DefaultArtifactClassLoaderResolver [main] [event: ]: Exported packages from artifact 'dev-test-kinesis' are provided by parent class loader: [org.apache.logging.log4j.status, org.apache.logging.log4j.core.appender.db.jdbc, org.apache.logging.log4j.core.config.yaml, org.apache.logging.log4j.core, org.apache.logging.log4j.core.config, org.apache.logging.log4j.core.appender, org.apache.logging.log4j.core.selector, org.apache.logging.log4j.core.config.plugins.validation.validators, org.apache.logging.log4j.core.tools, org.apache.logging.log4j.core.config.plugins.validation, org.apache.logging.log4j.core.net, org.apache.logging.log4j.core.appender.mom, org.apache.logging.log4j.core.config.properties, org.apache.logging.log4j.core.config.builder.impl, org.apache.logging.log4j.core.appender.mom.jeromq, org.apache.logging.log4j.core.config.plugins.util, org.apache.logging.log4j.core.time, org.apache.logging.log4j.core.net.ssl, org.apache.logging.log4j.core.async, org.apache.logging.log4j.core.config.status, org.apache.logging.log4j.core.config.arbiters, org.apache.logging.log4j.core.appender.db, org.apache.logging.log4j.core.lookup, org.apache.logging.log4j.core.config.plugins.validation.constraints, org.apache.logging.log4j.core.osgi, org.apache.logging.log4j.core.filter, org.apache.logging.log4j.core.util.datetime, org.apache.logging.log4j.spi, org.apache.logging.log4j.core.appender.rolling, org.apache.logging.log4j.core.layout, org.apache.logging.log4j.core.appender.routing, org.apache.logging.log4j.core.filter.mutable, org.apache.logging.log4j.core.config.builder.api, org.apache.logging.log4j.core.impl, org.apache.logging.log4j.core.config.json, org.apache.logging.log4j.core.config.plugins.processor, org.apache.logging.log4j, org.apache.logging.log4j.core.appender.rolling.action, org.apache.logging.log4j.message, org.apache.logging.log4j.util, org.apache.logging.log4j.core.pattern, org.apache.logging.log4j.core.config.xml, org.apache.logging.log4j.core.util, org.apache.logging.log4j.core.appender.rewrite, org.apache.logging.log4j.core.script, org.apache.logging.log4j.core.config.composite, org.apache.logging.log4j.core.config.plugins.convert, org.apache.logging.log4j.core.config.plugins.visitors, org.apache.logging.log4j.core.jmx, org.apache.logging.log4j.core.config.plugins, org.apache.logging.log4j.core.jackson, org.apache.logging.log4j.core.appender.nosql, org.apache.logging.log4j.core.parser, org.apache.logging.log4j.simple, org.apache.logging.log4j.core.appender.mom.kafka]

Cause

In the Mule runtime, the Log4j2 logging subsystem (the LoggerContext and the Log4j2 PluginManager that scans Log4j2Plugins.dat to discover appender plugins) is initialized by the Mule container / system class loader, not by the application class loader. All org.apache.logging.log4j.* packages are also served from the container class loader (see the DefaultArtifactClassLoaderResolver message above).

A custom appender packaged inside the application — or added via the mule-maven-plugin <sharedLibrary> element — lives in the child (application) class loader. Because Log4j2 plugin discovery runs at the container level, it does not scan the application JAR's Log4j2Plugins.dat descriptor, so the custom appender plugin is never registered. The custom appender element in log4j2.xml is silently ignored and the appender is never instantiated.

This does not occur locally because Anypoint Studio runs the application and Log4j2 in a single, flat class loader where the plugin descriptor is scanned normally.

This is a known limitation of the Mule runtime running on Cloud Hub 2.0 / Runtime Fabric environment.