Depending on API changes, we might just need a 2.x API shim. Say for example I have a custom plugin written for 2.x; it would be great if that still works fine in 3.x using said shim. I have some ideas brewing about plugin ASTs and transformations between them that might make this more manageable (might even help make the different config formats similarly manageable depending on how far the idea can stretch). I'm still thinking of how it would work before I write any proof of concept, though.
On Wed, 21 Aug 2019 at 13:30, Ralph Goers <[email protected]> wrote: > > That may be more of a documentation task. Although I had to remove revapi > from 3.0 due to all the changes I doubt they will impact very many users. I > know the work I did on moving the plugin support is backward compatible. > > Ralph > > > On Aug 21, 2019, at 10:27 AM, Matt Sicker <[email protected]> wrote: > > > > 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]> > > > > -- Matt Sicker <[email protected]>
