Closed pavel-klavik closed 2 years ago
Hello Pavel!
Before digging too deeply, we have removed the usage of aleph.utils.PluggableDnsAddressResolverGroup
.
It's not present anymore on the code-base, it has been removed by the following PR : https://github.com/clj-commons/aleph/pull/399/files.
Maybe you have a mismatch between multiple aleph versions. What is the state of your deps?
Hi Pavel.
In addition to what Arnaud said, what's the context you're using Aleph in? This sounds a lot like the sort of problem we see when multiple versions of a library end up on the classpath. Usually including an uberjar by accident is the reason. (E.g., Jepsen has a similar issue, related to deploying an uberjar that includes byte-streams and manifold.)
I would check for any uberjars in your classpath first. If in doubt, unzip them, look at the file list, and if any jars contain files/classes from elsewhere, they might be uberjars. Also, let us know if you're doing this with graal.
Based on the stacktrace, you're using orgpad-server
, and looking at its project.clj
, the first thing that looks suspicious is the dep on duct/server.http.aleph
. Also, onyx-platform apparently used to use Aleph, and its onyx-http plugin looks like it still does.
That being said, neither appear to build uberjars like orgpad-server itself does. If you were using the orgpad-server uberjar as a dep in another project, that might be the most likely cause of the problem.
Thanks for the pointers. I checked my dependencies with lein deps :tree
, but I couldn't find aleph included multiple times. The mentioned orgpad
is our project itself. In the end, I tried to run lein clean
and that fixed the problem.
I have a project when an upgrade from aleph-0.4.6 to 0.5.0 fails with the following stacktrace:
Any idea what could be causing this? The code does not interact with Aleph much, just starts the server at the beginning: