No shims are needed for plugins. The plugin manager still recognizes and handles the .dat files. The annotation processor just won’t generate them any more.
Ralph > On Aug 21, 2019, at 1:34 PM, Matt Sicker <[email protected]> wrote: > > 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]> >
