The 3.x code loads plugins from generated Java classes that correspond to ServiceLoader-loadable classes. Since each jar tends to end up with their generated plugin class going into different package names, the result of shading them together works naturally with combining the META-INF/services/ files. For the .dat file, that's a custom format that's essentially a light serialized form of the plugin metadata which has to be programmatically combined together. The ServiceLoader approach was eventually adopted as it works much better with the Java module system, though it also helps solve the shading problem, too, without additional tooling.
In the meantime, we could publish a Maven plugin or something to combine 2.x plugin .dat files into a single one. On Wed, Oct 13, 2021 at 9:34 AM Volkan Yazıcı <vol...@yazi.ci> wrote: > > It works on `master`. Matt, mind shedding some light on why it works on > `master`, but doesn't on `release-2.x`? Maybe we can backport the trick on > `master` to `release-2.x`? > > On Wed, Oct 13, 2021 at 4:05 PM Apache <ralph.go...@dslextreme.com> wrote: > > > We could include it in Log4J. Does master work out of the box? > > > > Ralph > > > > > On Oct 13, 2021, at 12:23 AM, Volkan Yazıcı <vol...@yazi.ci> wrote: > > > > > > > > > I have done something really nasty in the release-2.x branch to fix > > benchmarks.jar generated by log4j-perf. Since a picture is worth a thousand > > words, I am sharing two: > > > > > > > > > > > > (In case images get truncated, see commit 4049240c.) > > > > > > In a nutshell, Log4j2Plugins.dat of the shaded benchmarks.jar doesn't > > contain log4j-layout-template-json plugins due to overrides taking place > > during shading. This problem rendered the JsonTemplateLayout benchmarks > > broken after JTLs migration to plugins. Using a 3rd party Maven plugin > > circumventing a Log4j bug in the Log4j project itself felt pretty > > unpleasant to me. Is there any other way I could have solved this? > > > > > >
