Closed mdindoffer closed 1 year ago
I analyzed a similar report, see https://github.com/spring-projects/spring-framework/issues/30016#issuecomment-1444138210. We need to upgrade RSocket Java to reactor-bom 2020.0.28 and Netty 4.1.89.
Thanks @OlegDokuka @rstoyanchev for doing something about this. Unfortunately, although this has been closed for a month, there's been no release to try it out. Will we see 1.1.4 soon? We are still stuck on an old release of project Reactor because of this bug. Are we supposed to update to the latest and just exclude the netty-buffer
dependency from RSocket? Will everything work out of the box with the latest netty binaries, or should we expect problems with this approach?
Expected Behavior
I'd love to use the latest Reactor-BOM 2022.0.3 (which includes the reactor-netty 1.1.3 and that one in turn depends on netty 4.1.89) together with latest
rsocket-core
andrsocket-transport-netty
version 1.1.3.Actual Behavior
This combination does not work, I get
This is because while most of netty artifacts on the classpath are from 4.1.89,
netty-buffer
and consequentlynetty-common
is still version 4.1.81.Steps to Reproduce
Just use the latest reactor BOM and depend on latest
rsocket-core
andrsocket-transport-netty
.Possible Solution
I'm not very good with gradle, but I think this is the problem: https://github.com/rsocket/rsocket-java/blob/master/build.gradle#L38 I think the
reactor-netty
already includes the list of netty artifacts, but then you overwrite thenetty-buffer
dependency explicitly with an older one, instead of relying on transitive dependencies.Your Environment
netty
, ...): Reactor-BOM 2022.0.3javar -version
) or Node version (node --version
)): 17uname -a
): linux