In 3.x, isn't this replaced by code generation? I don't recall offhand how it names the file, so it might not even need to be concatenated there.
For changing the format of the cache in 2.x, besides the various transformer workarounds, I'm not sure of the implications of completely changing the format in 2.x would be. If we did change the format, it would make sense to be a plain text file such that it can easily be cat'd together at build time. On Wed, 21 Aug 2019 at 11:42, Gary Gregory <[email protected]> wrote: > > I had a similar problem to solve a while back. I used something like > https://github.com/edwgiz/maven-shaded-log4j-transformer > > Gary > > On Wed, Aug 21, 2019 at 12:20 PM Gregg Donovan <[email protected]> wrote: > > > Hello! > > > > I'm working on getting Etsy's custom StackdriverJsonLayout Log4J plugin to > > work with our Bazel-based build system and wanted to run a few ideas by > > you. > > > > The first problem I ran into was stdout messages breaking the > > PluginProcessor annotation processor when run by Bazel. My PR here[1] fixed > > that for us. > > > > The problem we have now is with "fat jars" and the plugin cache > > file > > (META-INF/org/apache/logging/log4j/core/config/plugins/Log4j2Plugins.dat)[2]. > > When Bazel builds a "deploy" jar, it combines an application's classes and > > the classes of its transitive dependencies into a single "fat" JAR. During > > this process it needs to intelligently combine any duplicate JAR entries it > > finds. > > > > Right now, Bazel does not know about the plugin cache file[3], so it keeps > > the first one it encounters and discards any others. So, our custom > > plugin's plugin cache file is discarded in the process.[4] > > > > Even if Bazel knew about the plugin cache file, I don't think the binary > > format is easily concatenated, due to the length header. [5] > > > > I have a few suggestions for fixing this that I'd like to run by you all > > before submitting a patch: > > > > Make the .dat files concatenateable, either textually (i.e. inserting a \n > > between combined files) or as binary data (i.e. no inserted bytes). This > > makes the job of the build tool much easier. > > There seem to be two options: > > a) Move from a binary format to textual (say, tab delimited PluginEntry > > fields) and combine the dat files as plain text. > > If this option is chosen, we could either teach Bazel's DefaultJarEntry > > filter to combine the plugin cache file textually or move it into > > META-INF/services, where all files are combined as textual data.[6] > > > > b) Remove the length header and allow the .dat files to be combined as > > binary data. > > If we choose this option, we would need to teach Bazel's > > DefaultJarEntryFilter to combine the plugin cache file as binary, as it > > does for proto files.[7] > > > > What do you think? Thanks for the consideration! > > > > Gregg > > > > [1]: https://github.com/apache/logging-log4j2/pull/301 > > [2]: > > > > https://github.com/apache/logging-log4j2/blob/cd87dd40405166a4d5f6707a27cbaf7ddcf833b6/log4j-plugins/src/main/java/org/apache/logging/log4j/plugins/processor/PluginProcessor.java#L67 > > [3]: > > > > https://github.com/bazelbuild/bazel/blob/master/src/java_tools/singlejar/java/com/google/devtools/build/singlejar/DefaultJarEntryFilter.java > > [4]: > > > > https://github.com/bazelbuild/bazel/blob/0d39361075b05919618720f961870d3863a726ac/src/java_tools/singlejar/java/com/google/devtools/build/singlejar/ZipEntryFilter.java#L87:L91 > > [5]: > > - > > > > https://github.com/apache/logging-log4j2/blob/92d19c8da6591a706a2df9875c7e41f6fb20bd66/log4j-core/src/main/java/org/apache/logging/log4j/core/config/plugins/processor/PluginCache.java#L73 > > - > > > > https://github.com/apache/logging-log4j2/blob/92d19c8da6591a706a2df9875c7e41f6fb20bd66/log4j-core/src/main/java/org/apache/logging/log4j/core/config/plugins/processor/PluginCache.java#L101 > > [6]: > > > > https://github.com/bazelbuild/bazel/blob/447e0f1aedb1d83feba2298b1e251b4e34ed9a70/src/java_tools/singlejar/java/com/google/devtools/build/singlejar/DefaultJarEntryFilter.java#L99:L101 > > [7]: > > > > https://github.com/bazelbuild/bazel/blob/447e0f1aedb1d83feba2298b1e251b4e34ed9a70/src/java_tools/singlejar/java/com/google/devtools/build/singlejar/DefaultJarEntryFilter.java#L115:L117 > > -- Matt Sicker <[email protected]>
