java.lang.IllegalArgumentException: The GraalVmProcessor annotation processor is missing the required log4j.graalvm.groupId and log4j.graalvm.artifactId options

[ratoaq2]

Hi all,

I have a java 21 maven project which uses eclipse compiler org.codehaus.plexus:plexus-compiler-eclipse:2.15.0 and has a log4j plugin using a Log4j2Plugins.dat file and configured the compiler with:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-compiler-plugin</artifactId>
  <executions>
    <execution>
      <id>generate-log4j-plugin-descriptor</id>
      <goals>
        <goal>compile</goal>
      </goals>
      <phase>process-classes</phase>
      <configuration>
        <proc>only</proc>
        <annotationProcessorPaths>
          <path>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-core</artifactId>
          </path>
        </annotationProcessorPaths>
        <annotationProcessors>
          <processor>org.apache.logging.log4j.core.config.plugins.processor.PluginProcessor</processor>
        </annotationProcessors>
      </configuration>
    </execution>
  </executions>
</plugin>

After upgrading from 2.24.3 to 2.25.0 now my compilation is failing with:

19:43:54  [INFO] --- compiler:3.14.0:compile (default-compile) @ common ---
19:43:55  [INFO] Recompiling the module because of changed source code.
19:43:55  [INFO] Compiling with eclipse [debug deprecation parameters target 21] to target/classes
19:43:55  [INFO] -------------------------------------------------------------
19:43:55  [ERROR] COMPILATION ERROR : 
19:43:55  [INFO] -------------------------------------------------------------
19:43:55  [ERROR] /redacted/XXXX/redacted/src/main/redacted/Redacted.java: Internal compiler error: java.lang.Exception: java.lang.IllegalArgumentException: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options.
19:43:55  The generation of GraalVM reflection metadata for your Log4j Plugins will be disabled. The generation of GraalVM reflection metadata for your Log4j Plugins will be disabled.
19:43:55  [ERROR] Unknown source: The `GraalVmProcessor` annotation processor is missing the required `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options.
19:43:55  The generation of GraalVM reflection metadata for your Log4j Plugins will be disabled.
19:43:55  [INFO] 2 errors 

Is anyone facing similar issue? I tried to specify the graal processor with its arguments, but that doesn't work either.

[kwakeroni]

I have the same issue.
The release notes say "the processor will fail the build if the required log4j.graalvm.groupId and log4j.graalvm.artifactId parameters are not provided", but according to this page: https://logging.apache.org/log4j/2.x/manual/plugins.html#plugin-registry the GraalVM stuff is optional.
I don't see an option to turn it off, though.

[ppkarwasz]

The warning in the release notes warning is a simplified explanation of the actual behavior. The GraalVmProcessor will only produce an error out when both of the following are true:

1. Your code includes at least one Log4j Core Plugin (i.e., you have a class annotated with @Plugin).

2. You did not supply the required compiler arguments:

   -Alog4j.graalvm.groupId=<your.groupId>
   -Alog4j.graalvm.artifactId=<your.artifactId>
   

I tested this locally (using javac in both single- and multi-module Maven setups) without any issues—no errors appeared when no @Plugin was present. Can you share a snippet or small test project where the issue does occur?

[THausherr]

            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <executions>
                <execution>
                    <id>generate-log4j-plugin-descriptor</id>
                    <goals>
                        <goal>compile</goal>
                    </goals>
                    <phase>process-classes</phase>
                    <configuration>
                        <proc>only</proc>
                        <annotationProcessorPaths>
                            <path>
                                <groupId>org.apache.logging.log4j</groupId>
                                <artifactId>log4j-core</artifactId>
                                <version>${log4j2.version}</version>
                            </path>
                        </annotationProcessorPaths>
                        <annotationProcessors>
                            <processor>org.apache.logging.log4j.core.config.plugins.processor.PluginProcessor</processor>
                            <processor>org.apache.logging.log4j.core.config.plugins.processor.GraalVmProcessor</processor>
                        </annotationProcessors>
                        <compilerArgs>
                            <arg>-Alog4j.graalvm.groupId=${project.groupId}</arg>
                            <arg>-Alog4j.graalvm.artifactId=${project.artifactId}</arg>
                        </compilerArgs>
                    </configuration>
                </execution>
            </executions>
        </plugin>

and I do have a plugin

@Plugin(name = "DebugLogAppender", category = "Core", elementType = "appender", printObject = true)
public class DebugLogAppender extends AbstractAppender

The subproject is here (the above segment has been removed because I reverted the change):
https://github.com/apache/pdfbox/tree/trunk/debugger

[ppkarwasz]

Hi @kwakeroni,

There’s no dedicated flag to turn GraalVmProcessor off, since you can effectively control it through standard compiler options.

As @ftreede mentioned, since Java 6, javac has automatically loaded all annotation processors found on the annotation processor path (which, by default, is just the classpath). This implicit behavior has been flagged as a security concern and is now deprecated as of Java 23 (see this JDK 23 heads-up and the excellent write-up here).

Keeping the spirit of the changes in JDK 23, we intentionally make GraalVmProcessor fail with an ERROR (instead of silently ignoring it or logging a warning) because:

• It helps developers become immediately aware that a new annotation processor is active.
• It forces an explicit decision: either configure it properly (opt-in) or disable it (opt-out).

✅ How to Opt-Out

Depending on whether you use other annotation processors, you can take one of two approaches:

1. You don’t use other annotation processors

You can simply disable all annotation processing:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-compiler-plugin</artifactId>
  <configuration>
    <!-- Completely disable annotation processing -->
    <proc>none</proc>
  </configuration>
</plugin>

2. You do use other annotation processors

In this case, declare them explicitly and isolate your annotation processor classpath:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-compiler-plugin</artifactId>
  <configuration>
    <annotationProcessorPaths>
      <!-- Include only specific processors, e.g. Log4j’s PluginProcessor -->
      <path>
        <groupId>org.apache.logging.log4j</groupId>
        <artifactId>log4j-core</artifactId>
        <version>2.25.0</version>
      </path>
    </annotationProcessorPaths>
    <annotationProcessors>
      <!-- List processors explicitly -->
      <annotationProcessor>org.apache.logging.log4j.core.config.plugins.processor.PluginProcessor</annotationProcessor>
    </annotationProcessors>
  </configuration>
</plugin>

This ensures that only the processors you trust and need are loaded—nothing more, nothing less.

✅ How to Opt-In

An example on to use both PluginProcessor and GraalVmProcessor is available on the documentation page you site

[ppkarwasz]

@THausherr,

I couldn't reproduce your problems with PDFBox. I submitted my changes as apache/pdfbox#207.

[THausherr]

Thank you! I also suggest that the log4j documentation be updated, with the links that you provided in your PR.

[ppkarwasz]

Hi @ratoaq2,

Thanks for the detailed error log — it's very helpful.

From what you've shared, the issue is occurring during the default-compile Maven Compiler Plugin execution, not in the custom generate-log4j-plugin-descriptor execution you configured. Specifically:

[INFO] --- compiler:3.14.0:compile (default-compile) @ common ---
[INFO] Compiling with eclipse [...] to target/classes
[ERROR] Internal compiler error: java.lang.IllegalArgumentException: 
        The `GraalVmProcessor` annotation processor is missing the required 
        `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options.

If you want to use a separate execution for annotation processing, you need to disable annotation processing in default-compile:

<execution>
  <id>default-compile</id>
  <configuration>
    <proc>none</proc>
  </configuration>
</execution>

If, on the other hand, you want to perform both compilation and annotation processing (Log4j plugin descriptor + GraalVM metadata) in a single Maven execution, you can fully configure the default-compile phase like this:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-compiler-plugin</artifactId>
  <version>3.14.0</version>
  <dependencies>
    <dependency>
      <groupId>org.codehaus.plexus</groupId>
      <artifactId>plexus-compiler-eclipse</artifactId>
      <version>2.15.0</version>
    </dependency>
  </dependencies>
  <configuration>
    <!-- Use Eclipse Compiler explicitly -->
    <compilerId>eclipse</compilerId>
    <release>21</release>
    <!-- Default to no annotation processing unless explicitly enabled -->
    <proc>none</proc>
  </configuration>
  <executions>
    <execution>
      <id>default-compile</id>
      <configuration>
        <annotationProcessorPaths>
          <path>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-core</artifactId>
            <version>2.25.0</version>
          </path>
        </annotationProcessorPaths>
        <annotationProcessors>
          <annotationProcessor>
            org.apache.logging.log4j.core.config.plugins.processor.PluginProcessor
          </annotationProcessor>
          <annotationProcessor>
            org.apache.logging.log4j.core.config.plugins.processor.GraalVmProcessor
          </annotationProcessor>
        </annotationProcessors>
        <compilerArgs>
          <!-- Required arguments for GraalVmProcessor -->
          <arg>-Alog4j.graalvm.groupId=${project.groupId}</arg>
          <arg>-Alog4j.graalvm.artifactId=${project.artifactId}</arg>
        </compilerArgs>
      </configuration>
    </execution>
  </executions>
</plugin>

I hope that helps solving your problem.

[THausherr]

I tried the last change with default-compile and now the project that follows the problematic project claims that the previous package doesn't exist. I looked into the repository directory, the jar files are there, but much smaller. It turned out the class files are missing.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <executions>
        <execution>
            <id>default-compile</id>
            <configuration>
                <proc>only</proc>
                <annotationProcessorPaths>
                    <path>
                        <groupId>org.apache.logging.log4j</groupId>
                        <artifactId>log4j-core</artifactId>
                        <version>${log4j2.version}</version>
                    </path>
                </annotationProcessorPaths>
                <annotationProcessors>
                    <annotationProcessor>org.apache.logging.log4j.core.config.plugins.processor.PluginProcessor</annotationProcessor>
                    <annotationProcessor>org.apache.logging.log4j.core.config.plugins.processor.GraalVmProcessor</annotationProcessor>
                </annotationProcessors>
                <compilerArgs>
                    <arg>-Alog4j.graalvm.groupId=${project.groupId}</arg>
                    <arg>-Alog4j.graalvm.artifactId=${project.artifactId}</arg>
                </compilerArgs>
            </configuration>
        </execution>
    </executions>
</plugin>

[ppkarwasz]

Nice catch! 💯
Somehow <proc>only</proc> ended up in my example, which disables the compilation of classes. I edited the answer to fix it.

[THausherr]

Thank you! It builds successfully now. I see you also made a (slightly different) PR, I'll have a look at it tomorrow.

[ratoaq2]

It seems I got it working with proc none plus empty annotation processors:

                <annotationProcessorPaths>
                    <path>
                        <groupId>org.apache.logging.log4j</groupId>
                        <artifactId>log4j-core</artifactId>
                        <version>${log4j2.version}</version>
                    </path>
                </annotationProcessorPaths>
                <annotationProcessors>
                    <!-- empty -->
                </annotationProcessors>

[ratoaq2]

It seems a bit cumbersome for a project that has nothing to do with Graalvm

[kwakeroni]

I agree. I have no annotation processors configured in my pom, all running out-of-the-box (like Lombok), and now I would need add about 20 lines just to turn of a feature because I'm using a custom appender (internal to the project) in my tests...

[ppkarwasz]

Thank you for your feedback!

You're absolutely right — we hadn’t fully considered the case of custom Log4j plugins used only in test code when implementing GraalVM metadata support in Log4j Core.

As a general principle, we encourage third-party Log4j Core plugins to follow the same standards as Log4j Core itself. This ensures consistent behavior across platforms and helps users discover and rely on high-quality extensions. In particular:

• We aim to list community plugins on our website (organized by type — e.g., Appenders, Layouts, Lookups), so they’re easier to find.
• We encourage support for the same platforms as Log4j Core: standard Java, JPMS, OSGi, GraalVM, and Android.

This is why we initially followed the GraalVM reachability metadata documentation strictly, which recommends placing reflect-config.json files in META-INF/native-image/<groupId>/<artifactId> — and why we introduced the -Alog4j.graalvm.groupId and -Alog4j.graalvm.artifactId compiler options to set those values explicitly.

That said, your feedback (and others') made it clear that requiring these options can be a burden in some scenarios.

Tools like picocli take a more flexible approach by making similar arguments optional, falling back to default values when not provided. Following this model, we will make the -Alog4j.graalvm.groupId and -Alog4j.graalvm.artifactId arguments optional starting in version 2.25.1. Defaults will be inferred if these are not explicitly specified, similar to how picocli handles this.

For more details on the 2.25.1 release scope and timeline, see #3766.

Thanks again for raising this — improving the developer experience for plugin authors is a priority for us.

[kwakeroni]

Thank you for taking this into account

[alexsuter]

Tried to making work with tycho-compiler-plugin. Did not find any solution to fix the build with the given configurations. Also my project has no GraalVM stuff in it.

[ppkarwasz]

I'm not a Tycho user, but from what I can tell, the configuration for tycho-compiler-plugin is quite similar to maven-compiler-plugin in this context.

I tested this successfully on a small example project using Tycho version 4.0.13 with a custom Log4j appender. To ensure the Log4j GraalVmProcessor works correctly, I added the following configuration:

<plugin>
  <groupId>org.eclipse.tycho</groupId>
  <artifactId>tycho-compiler-plugin</artifactId>
  <configuration>
    <compilerArgs>
      <arg>-Alog4j.graalvm.groupId=${project.groupId}</arg>
      <arg>-Alog4j.graalvm.artifactId=${project.artifactId}</arg>
    </compilerArgs>
  </configuration>
</plugin>

Also my project has no GraalVM stuff in it.

A quick clarification: the GraalVmProcessor is not triggered by using GraalVM itself. Instead, it is activated by the presence of custom Log4j Core plugins in your code—specifically, classes annotated with @org.apache.logging.log4j.core.config.plugins.Plugin.

Hope this helps clarify things!

[alexsuter]

This works. Thanks!

[jbisotti]

To keep deprecated code out of our codebase, we enable deprecation warnings and treat compilation warnings as errors, in order to break the build and call attention to the deprecated code usage.

                <plugin>
                    <artifactId>maven-compiler-plugin</artifactId>
                    <version>3.13.0</version>
                    <configuration>
                        <compilerArgs>

                            <!-- Treat Warnings as Errors -->
                            <arg>-Werror</arg>

                            <!-- Enable deprecation warnings -->
                            <arg>-Xlint:deprecation</arg>

                        </compilerArgs>
                        <showWarnings>true</showWarnings>
                        <!-- https://issues.apache.org/jira/browse/MCOMPILER-209 -->
                        <useIncrementalCompilation>false</useIncrementalCompilation>
                    </configuration>
                </plugin>

We do not use Graal.
We do not have any custom annotation processors.
We do not have any @PluginS.
We do use Mockito.

I tried upgrading from 2.24.3 to 2.25.1 but the build fails with:

...
[INFO] --- compiler:3.13.0:testCompile (default-testCompile) @ kfs-core ---
[INFO] Compiling 954 source files with javac [debug release 21] to target/test-classes
[INFO] Annotation processing is enabled because one or more processors were found
  on the class path. A future release of javac may disable annotation processing
  unless at least one processor is specified by name (-processor), or a search
  path is specified (--processor-path, --processor-module-path), or annotation
  processing is enabled explicitly (-proc:only, -proc:full).
  Use -Xlint:-options to suppress this message.
  Use -proc:none to disable annotation processing.
[INFO] GraalVmProcessor: writing GraalVM metadata for 2 Java classes to `META-INF/native-image/log4j-generated/cb86055/reflect-config.json`.
[INFO] PluginProcessor: writing plugin descriptor for 4 Log4j Plugins to `META-INF/org/apache/logging/log4j/core/config/plugins/Log4j2Plugins.dat`.
[INFO] -------------------------------------------------------------
[WARNING] COMPILATION WARNING : 
[INFO] -------------------------------------------------------------
[WARNING] The `GraalVmProcessor` annotation processor is missing the recommended `log4j.graalvm.groupId` and `log4j.graalvm.artifactId` options.
  To follow the GraalVM recommendations, please add the following options to your build tool:
    -Alog4j.graalvm.groupId=<groupId>
    -Alog4j.graalvm.artifactId=<artifactId>
[INFO] 1 warning
[INFO] -------------------------------------------------------------
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR : 
[INFO] -------------------------------------------------------------
[ERROR] warnings found and -Werror specified
[INFO] 1 error
...

Due to our steps to keep deprecated code out of the codebase, this warning, for something we do not use and do not care about, is breaking the build. It doesn't make sense to have to provide useless configuration in N different builds to make this go away.

[ppkarwasz]

Hi @jbisotti,

Thanks for the feedback regarding version 2.25.1 — much appreciated!

We do not have any @Plugins.

That’s mostly true — your main code doesn’t define any Log4j @Plugins, which is why the GraalVmProcessor isn’t triggered during the default-compile phase. The warning about unrecognized annotation processor options appears when either no annotation processor recognizes the specified options, or the processor that does recognize them isn’t triggered because it has no relevant annotations to process:

[INFO] --- maven-compiler-plugin:3.13.0:compile (default-compile) @ kfs-core ---
...
[WARNING] The following options were not recognized by any processor: '[log4j.graalvm.artifactId, log4j.graalvm.groupId]'

However, the story is a bit different during test compilation. As you can see this from the processor output, the GraalVmProcessor is triggered during the default-testCompile phase:

[INFO] --- maven-compiler-plugin:3.13.0:testCompile (default-testCompile) @ kfs-core ---
...
[INFO] GraalVmProcessor: writing GraalVM metadata for 2 Java classes to `META-INF/native-image/log4j-generated/cb86055/reflect-config.json`.

To eliminate the warnings about unrecognized options while keeping everything working correctly, you can limit the annotation processor options to just the default-testCompile phase like this:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-compiler-plugin</artifactId>
  <version>3.13.0</version>
  <configuration>
    <compilerArgs>
      <arg>-Werror</arg>
      <arg>-Xlint:deprecation</arg>
    </compilerArgs>
    <showWarnings>true</showWarnings>
    <useIncrementalCompilation>false</useIncrementalCompilation>
  </configuration>
  <executions>
    <execution>
      <id>default-testCompile</id>
      <configuration>
        <compilerArgs combine.children="append">
          <arg>-Alog4j.graalvm.groupId=${project.groupId}</arg>
          <arg>-Alog4j.graalvm.artifactId=${project.artifactId}</arg>
        </compilerArgs>
      </configuration>
    </execution>
  </executions>
</plugin>

[ppkarwasz]

Due to our steps to keep deprecated code out of the codebase, this warning — for something we neither use nor care about — is breaking the build. It doesn't make sense to have to provide useless configuration in N different builds just to silence it.

I completely understand the frustration of a build breaking due to what seems like irrelevant configuration. But since you're clearly invested in keeping your codebase clean and free of deprecated elements, this might actually be a good opportunity to evaluate a few things:

1. Why is log4j-core on your compile classpath?

log4j-core is the standard implementation of the Log4j API and is typically only needed at runtime. However, we often see it added with compile scope — even when it's not strictly necessary. Unless you're writing custom Log4j plugins or manipulating internal APIs (which we generally advise against), log4j-core should be declared with runtime scope.

📘 See: Log4j Manual – Installing a Logging Implementation

If you're not developing Log4j plugins, does log4j-core really need to be on your compile classpath?

Some projects include log4j-core to perform programmatic logging configuration at runtime. While that may seem reasonable, it typically creates tight coupling to a specific logging implementation, which can make it difficult for downstream users to swap in a different backend (e.g., JUL, Logback, etc.).

To address this limitation, we're open to introducing a backend-agnostic API for safely modifying logger behavior at runtime. A preliminary proposal is available in the logging-admin project, and we're actively looking for real-world use cases to help shape the design. If your project depends on this kind of programmatic configuration, we’d really appreciate your input.

2. Do you really need custom Log4j plugins in tests?

We’ve noticed several users (including some in this discussion) define custom Log4j plugins for unit tests — but we rarely receive feature requests to improve the log4j-core-test module, which provides ready-made test fixtures like ListAppender.

If you're writing custom plugins purely to verify logging behavior, could you share what ListAppender is missing for you? The last feedback we received on this was back in 2022 (log4j-user thread).

We’d genuinely welcome a discussion or issue detailing your test needs — it's the kind of input that helps shape better tooling for everyone.

[jbisotti]

Apologies; I misspoke yesterday.

We recently added a unit test to verify the contents of a log message, including the context keys/values. I likely missed something but I couldn't find an easy way to do that. I ended up borrowing ListAppender from log4j-core-test so our test code did in fact contain an @Plugin. I've now removed this and added log4j-core-test as a test dependency.

Also, we intentionally had log4j-core as a compile dependency because the code includes a few CLI utilities and on of them was using Configurator.initialize(...). I've now removed this and changed it to a runtime dependency.

With the the two changes above, and not doing anything special to deal with the GraalVM annotation processor issue, my code now compiles cleanly and the tests run successfully.

That said, adding the log4j-core-test dependency was not as clean as one would hope. It has a lot of undesirable transitive dependencies (Maven? Spring?). Literally, all I needed was ListAppender.

        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-core-test</artifactId>
            <version>${log4j.version}</version>
            <scope>test</scope>
            <exclusions>
                <exclusion>
                    <groupId>com.google.code.java-allocation-instrumentor</groupId>
                    <artifactId>java-allocation-instrumentor</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>commons-io</groupId>
                    <artifactId>commons-io</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>junit</groupId>
                    <artifactId>junit</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>org.apache.commons</groupId>
                    <artifactId>commons-lang3</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>org.assertj</groupId>
                    <artifactId>assertj-core</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>org.awaitility</groupId>
                    <artifactId>awaitility</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>org.hamcrest</groupId>
                    <artifactId>hamcrest</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>org.junit.jupiter</groupId>
                    <artifactId>junit-jupiter-api</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>org.junit.platform</groupId>
                    <artifactId>junit-platform-commons</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>org.springframework</groupId>
                    <artifactId>spring-test</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>org.apache.maven</groupId>
                    <artifactId>maven-core</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>org.apache.maven</groupId>
                    <artifactId>maven-model</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>org.codehaus.plexus</groupId>
                    <artifactId>plexus-utils</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>org.junit-pioneer</groupId>
                    <artifactId>junit-pioneer</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>org.mockito</groupId>
                    <artifactId>mockito-core</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

Like I said, I likely missed something; however, it would be great if there were some small/simple artifact with minimal dependencies with the aim of making unit testing logging easier. Unit testing logging likely isn't an ideal thing to do in general but sometimes it's necessary.

Thanks!

[ppkarwasz]

Also, we intentionally had log4j-core as a compile dependency because the code includes a few CLI utilities and on of them was using Configurator.initialize(...). I've now removed this and changed it to a runtime dependency.

That’s a common use case—many projects (like Spring Boot and Kafka) use log4j-core at compile scope to modify the logging configuration at runtime.

While Configurator is a supported API, it has drawbacks:

• It tightly couples your code to Log4j Core, making backend switching difficult. Both Kafka and Spring Boot need to properly isolate this code to make log4j-core optional.
• It doesn’t handle multiple logger contexts well—only the caller’s context is modified.

As I mentioned above we're working on a more flexible, backend-agnostic API in logging-admin. It aims to simplify configuration tasks and avoid dependency/linkage issues. One open question is how to safely support shared logging environments—see apache/logging-admin#1. Feedback is welcome!

That said, adding the log4j-core-test dependency was not as clean as one would hope. It has a lot of undesirable transitive dependencies (Maven? Spring?). Literally, all I needed was ListAppender.
[...]
Like I said, I likely missed something; however, it would be great if there were some small/simple artifact with minimal dependencies with the aim of making unit testing logging easier. Unit testing logging likely isn't an ideal thing to do in general but sometimes it's necessary.

You're absolutely right about log4j-core-test—it brings in a number of unnecessary dependencies for most users. Some of them (like Maven) may no longer be needed, while others (like JUnit 4 and Hamcrest) we’ve had to manually exclude in certain artifacts.

I’ve opened #3832 to track the idea of publishing a lightweight, dedicated test artifact with minimal dependencies. Thanks again for the valuable feedback!

[jbisotti]

Thank you! I appreciate your helpfulness and all your hard work on this project.