Plus the story of how we approach backward compatibility with 2.x in 3.x (e.g., renamed package, compatibility shims, etc.)
On Wed, 21 Aug 2019 at 12:19, Ralph Goers <[email protected]> wrote: > > The stability should be fine. We have continually port all bug fixes and > enhancements on the release-2.x branch to master. The main goal of 3.0 is to > split up the core module and to make each module a valid Java Module. We have > not completely finished that work. Basically, that is the only thing holding > up its release. Right now Log4j 3 is targeted at Java 8 but we might want to > consider making the base Java 9 to make our life easier as there is a whole > bunch of code we could dump if we did that. > > Ralph > > > On Aug 21, 2019, at 10:11 AM, Gregg Donovan <[email protected]> wrote: > > > > Thanks, Ralph, that makes sense as a way forward. > > > > Do you have any estimates on when 3.0 might be GA and/or an estimate of the > > stability of the current snapshot release? We'll likely stick with our fork > > in production until 3.0 is GA. > > > > On Wed, Aug 21, 2019 at 12:58 PM Ralph Goers <[email protected]> > > wrote: > > > >> I think you need to try with a SNAPSHOT of 3.0. As I mentioned in a > >> previous email 3.0 now longer generates a .dat file but generates a Java > >> source file that gets compiled with your source code instead. It also > >> requires a .service file for ServiceLoader but those should be handled out > >> of the box by shading tools. > >> > >> Ralph > >> > >>> On Aug 21, 2019, at 9:20 AM, 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]>
