It looks like someone attempted to shade Curator 2.13.0 and Curator 3.3.0, but it was only done for curator-client.
I know they're very old releases, but is it possible that we could get a Curator-2.13.1 and Curator-3.3.1 that also shades curator-framework, curator-x-discovery, etc.? An official fork would be better than an internal fork. On Tue, Dec 14, 2021 at 2:51 AM Jordan Zimmerman <jor...@jordanzimmerman.com> wrote: > Is there a way out of this situation without deploying our own > custom-patched Curator 2 or Curator 3 in which we remove Guava > dependencies? Merely upgrading to Guava 17 isn't much of a win for us (and > meanwhile our automated security scanners keep yelling at us for using > outdated libraries) > > > If you're unable to upgrade you could create a shaded version of Curator > maybe with the Maven Shade plugin. This would require an internal fork for > you though. > > I'm not familiar with CURATOR-526 and ZOOKEEPER-3577 to comment on those. > > -JZ > > On Dec 14, 2021, at 12:48 AM, Phong X. Nguyen <p.ngu...@yahooinc.com> > wrote: > > I posted about this earlier this year but I'm not sure if this was fully > resolved. > > We're currently on Guava 14, Zookeeper 3.5.7 and Curator 2.4.2. > > We'd like to upgrade to a reasonably recent version of Guava. That > requires an upgrade to Curator 4, but that brings in the problem reported > in CURATOR-526 and ZOOKEEPER-3577. Our Zookeeper configuration uses the old > securedClientPort setting, which is currently unavailable in the new > Dynamic Reconfiguration file format and thus is rejected by Zookeeper's new > EnsembleTracker. > > As far as I can tell, CURATOR-526 just silences the log message, but upon > trying to read through the code, it doesn't look like the internal > EnsembleTracker will be properly populated as it won't read the old > securedClientPort configuration. If that can't be resolved, for newer > versions of Zookeeper, is there an alternative to securedClientPort? > > Is there a way out of this situation without deploying our own > custom-patched Curator 2 or Curator 3 in which we remove Guava > dependencies? Merely upgrading to Guava 17 isn't much of a win for us (and > meanwhile our automated security scanners keep yelling at us for using > outdated libraries) > > Sorry to bug everyone again, but the old version of Guava that we're stuck > with is starting to cause serious problems as certain libraries are > requiring newer versions of Guava, and we cannot upgrade (even to fix > CVEs). > > Thanks, > - Phong X. Nguyen > > >
