onobc opened a new pull request, #18646: URL: https://github.com/apache/pulsar/pull/18646
### Motivation ℹ️ _**NOTE:** Taken from the "Motivation" section of the reported issue https://github.com/apache/pulsar/issues/18644._ When running on a Java client on Mac M1 we receive the annoying `WARN` log statement: > 22:07:00.494 [Test worker] WARN org.apache.pulsar.shade.io.netty.resolver.dns.DnsServerAddressStreamProviders - Can not find org.apache.pulsar.shade.io.netty.resolver.dns.macos.MacOSDnsServerAddressStreamProvider in the classpath, fallback to system defaults. This may result in incorrect DNS resolutions on MacOS. This can lead to actual issues - but in most cases is just an annoyance. The suggested workaround is to add the M1-specific dependency [netty-resolver-dns-native-macos]( https://mvnrepository.com/artifact/io.netty/netty-resolver-dns-native-macos/4.1.85.Final) when running on M1 ([example](https://github.com/netty/netty/issues/11020#issuecomment-1193280582)). However, this does **NOT** work for Pulsar when using the `pulsar-client-all` shared jar because it attempts to load the M1 version w/ the shaded prefix (`org.apache.pulsar.shade.io.netty.resolver.dns.macos.MacOSDnsServerAddressStreamProvider` rather than `io.netty.resolver.dns.macos.MacOSDnsServerAddressStreamProvider`). ### Modifications Let's define a couple of terms (as used in this proposal) before explaining the modifications: * **Shading** - the process of running the maven-shade-plugin to generate an uber jar w/ zero or more of its classes relocated from one package to another * **Relocating** - the process of renaming a class from one package to another (aka relocating) in order to effectively "hide" it from any of the same classes already on the user's classpath. The Netty DNS components w/ the following package name patterns: - `io.netty.resolver.dns.macos.*` - `io.netty.resolver.dns.*` are excluded from _relocation_ during _shading_ in the following modules: - `pulsar-client-shaded` - `pulsar-admin-client-shaded` - `pulsar-client-all` They are **still included in the uber jar** but are **not relocated** to a "shaded" prefix package name. The result is that the suggested workaround mentioned above is now possible - the M1 specific dependency can be added and proper DNS resolution can take place. ℹ️ _**NOTE:** I attempted to only shade the `io.netty.resolver.dns.macos.*` package but that ultimately failed at runtime because the `DnsServerAddressStreamProviders` casts the impl to a `DnsServerAddressStreamProvider` (the shaded one if it too has been shaded). Therefore I had to also exclude `io.netty.resolver.dns.*` to make it work._ ### Caveat A negative aspect of this solution is that the `io.netty.resolver.dns**` packages are not relocated (shaded) in the resulting jar. If the user has a conflicting version of the Netty DNS lib(s) then they will need to exclude the non-shaded Netty DNS lib from the "shaded" Pulsar jar. IOW - one of the primary purposes of relocation/shading is no longer in play for the Netty DNS libs. That being said, some other libs are already being excluded during the shading process - this is not a first. ### Verifying this change - [ ] Make sure that the change passes the CI checks. This change added no tests. ### Documentation ℹ️ _**NOTE:** It seems we should document what is/not shaded in the resulting libs somewhere. I will look to see if that place already exists. Other than that, the information below is accurate._ - [ ] `doc` <!-- Your PR contains doc changes --> - [ ] `doc-required` <!-- Your PR changes impact docs and you will update later --> - [x] `doc-not-needed` <!-- Your PR changes do not impact docs --> - [ ] `doc-complete` <!-- Docs have been already added --> ### Matching PR in forked repository PR in forked repository: https://github.com/onobc/pulsar/pull/2 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
