fix: restore Log4j2Plugins.dat in apm-toolkit-log4j-2.x

[waterWang]

Problem

Since 9.5.0, the released apm-toolkit-log4j-2.x jar no longer contains the Log4j2 plugin descriptor:

META-INF/org/apache/logging/log4j/core/config/plugins/Log4j2Plugins.dat

Without that descriptor Log4j2 cannot discover TraceIdConverter, so %traceId and %sw_ctx in a PatternLayout silently break — they are greedily matched as the built-in %t (thread name) followed by literal text.

Verified against Maven Central:

Version	Log4j2Plugins.dat
9.0.0 – 9.4.0	present
9.5.0 – 9.7.0	missing

Root Cause

9.5.0 added an annotationProcessorPaths block to maven-compiler-plugin in the root pom.xml, listing only Lombok. Once annotationProcessorPaths is declared explicitly, javac stops discovering annotation processors from the compile classpath. The log4j-core jar is declared as provided in this module, and Log4j2's PluginProcessor — previously picked up from that classpath — is what generates Log4j2Plugins.dat. With the processor list narrowed to Lombok only, PluginProcessor never runs and the descriptor is silently dropped.

Fix

Declare the compiler plugin in this module with annotationProcessorPaths containing both Lombok (preserving parent behaviour) and log4j-core (restoring the PluginProcessor).

Verification

The module's Java source files (TraceIdConverter, SkyWalkingContextConverter, Log4j2OutputAppender, Log4j2SkyWalkingContextOutputAppender) do not use Lombok annotations, so adding it to the path is safe but optional.

References

• Reported upstream: [Bug] apm-toolkit-log4j-2.x jar has been missing Log4j2Plugins.dat since 9.5.0, breaking %traceId, %sw_ctx and GRPCLogClientAppender skywalking#14006

[wu-sheng]

Could you update the changes.md about this?

[wu-sheng]

The fix is in the right place — module POM rather than root. Two notes on the form.

1. Prefer combine.children="append" over repeating the Lombok entry

annotationProcessorPaths inherits with replace semantics, so a child list wins entirely — which is exactly why Lombok has to be repeated here. Maven's combine.children="append" avoids the duplication: the module declares only what it adds, and the parent's entries are inherited.

<annotationProcessorPaths combine.children="append">
    <path>
        <groupId>org.apache.logging.log4j</groupId>
        <artifactId>log4j-core</artifactId>
        <version>${log4j-core.version}</version>
    </path>
</annotationProcessorPaths>

Verified locally — the resulting javac invocation carries both entries, and the descriptor comes back:

-processorpath lombok-1.18.42.jar     <- inherited from the root POM
               log4j-core-2.7.jar     <- declared here
→ META-INF/org/apache/logging/log4j/core/config/plugins/Log4j2Plugins.dat (380 bytes)

Its content is identical to the descriptor shipped in 9.4.0 and earlier: TraceIdConverter, SkyWalkingContextConverter, GRPCLogClientAppender.

The reason to prefer this is not brevity — it is that the replace form reproduces this very bug one level up. If the root POM ever gains another global processor, every module that declared its own annotationProcessorPaths would silently stop receiving it. That is the same silent failure mode being fixed here.

2. On "safe but optional"

The module's Java source files ... do not use Lombok annotations, so adding it to the path is safe but optional.

Accurate today, but the wording invites someone to drop that entry later, and the resulting failure would be precisely the build error #767 fixed — cannot find symbol on a Lombok-generated accessor, with nothing in the diff pointing at the cause. With combine.children="append" the question does not arise at all.

Either way, a guard is still needed

Neither form is self-defending: if the configuration is dropped, reordered, or overridden, the descriptor silently disappears again — no warning, no build failure, just a jar that is missing 380 bytes. Worth adding the build-time assertion the issue suggests, so the next occurrence fails the build instead of reaching three releases. I can send that as a follow-up.