Closed ebdekock closed 3 years ago
That is interesting. Are you using the Connect to a running REPL command?
I create a new lein project:
~/Scratch/clojure lein new lag
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by mranderson048.orchard.v0v3v0.dynapath.v0v2v5.dynapath.defaults$eval1931$fn__1932 to method java.net.URLClassLoader.addURL(java.net.URL)
WARNING: Please consider reporting this to the maintainers of mranderson048.orchard.v0v3v0.dynapath.v0v2v5.dynapath.defaults$eval1931$fn__1932
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Warning: refactor-nrepl needs to run in the context of a project.
Warning: refactor-nrepl middleware won't be activated.
Generating a project called lag based on the 'default' template.
The default template is intended for library projects, not applications.
To see other templates (app, plugin, etc), try `lein help new`.
~/Scratch/clojure lein --version
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by mranderson048.orchard.v0v3v0.dynapath.v0v2v5.dynapath.defaults$eval1931$fn__1932 to method java.net.URLClassLoader.addURL(java.net.URL)
WARNING: Please consider reporting this to the maintainers of mranderson048.orchard.v0v3v0.dynapath.v0v2v5.dynapath.defaults$eval1931$fn__1932
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Warning: refactor-nrepl needs to run in the context of a project.
Warning: refactor-nrepl middleware won't be activated.
Leiningen 2.9.5 on Java 11.0.7 OpenJDK 64-Bit Server VM
and then Im using Start a REPL and connect (Jack-in) This is the output in vscode terminal:
lein update-in :dependencies conj '[nrepl,"0.8.3"]' -- update-in :dependencies conj '[clj-kondo,"2020.04.05"]' -- update-in :plugins conj '[cider/cider-nrepl,"0.25.6"]' -- update-in '[:repl-options,:nrepl-middleware]' conj '["cider.nrepl/cider-middleware"]' -- repl :headless
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by mranderson048.orchard.v0v3v0.dynapath.v0v2v5.dynapath.defaults$eval1935$fn__1936 to method java.net.URLClassLoader.addURL(java.net.URL)
WARNING: Please consider reporting this to the maintainers of mranderson048.orchard.v0v3v0.dynapath.v0v2v5.dynapath.defaults$eval1935$fn__1936
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by mranderson048.orchard.v0v3v0.dynapath.v0v2v5.dynapath.defaults$eval3516$fn__3517 to method java.net.URLClassLoader.addURL(java.net.URL)
WARNING: Please consider reporting this to the maintainers of mranderson048.orchard.v0v3v0.dynapath.v0v2v5.dynapath.defaults$eval3516$fn__3517
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
nREPL server started on port 49549 on host 127.0.0.1 - nrepl://127.0.0.1:49549
This gets more and more intriguing... I was sure I could tell you to try with Jack-in instead, since that is where we bumped the cider-nrepl
version.
I can't reproduce this. But I am on an older Leiningen (2.9.1, I don't know why) so it is not a complete repro attempt. I am also using JDK 12, but neither of this should have to do with why requests are sent to clojuredocs...
Do you have a clue on what could be going on here, @bbatsov ? I know that in the past Leiningen could sometimes be clinging on to its own versions of nrepl stuff, but that has been sorted since then, I think?
There are no more requests to the legacy netlify site for sure, so unless there's an old version of cider-nrepl
lying around I can't imagine how this can still be a problem. Looking at the output you've posted this doesn't seem to be the case.
I certainly can't reproduce this.
It very much looks like an older version of cider-nrepl is being used than the one that's injected at jack-in, both because of those requests that are no longer made in the latest cider-nrepl, and also because of the warning Illegal reflective access by mranderson048.orchard.v0v3v0
(see here). The latest cider-nrepl usees version 0.6.2
of orchard, which uses version 1.1.0
of dynapath. I'm getting off on a tangent... :smile:
@ebdekock I'd run lein classpath
in your project directory and see if there's some older version of cider-nrepl there. Perhaps it could be coming from some other dependency.
@bpringe Great observations! I should have been more careful when inspecting the output. I only read the first line:
lein update-in :dependencies conj '[nrepl,"0.8.3"]' -- update-in :dependencies conj '[clj-kondo,"2020.04.05"]' -- update-in :plugins conj '[cider/cider-nrepl,"0.25.6"]' -- update-in '[:repl-options,:nrepl-middleware]' conj '["cider.nrepl/cider-middleware"]' -- repl :headless
Which seems correct to me.
Thanks, thats helped! There is an older version of cider-nrepl in the classpath, but I cant seem to figure out where its coming from.. If I wipe out the cider folder in: ~/.m2/repository rm -rf cider
and I restart a REPL, it reinstalls it:
lein update-in :dependencies conj '[nrepl,"0.8.3"]' -- update-in :dependencies conj '[clj-kondo,"2020.04.05"]' -- update-in :plugins conj '[cider/cider-nrepl,"0.25.6"]' -- update-in '[:repl-options,:nrepl-middleware]' conj '["cider.nrepl/cider-middleware"]' -- repl :headless
Retrieving cider/cider-nrepl/0.22.4/cider-nrepl-0.22.4.pom from clojars
Retrieving cider/cider-nrepl/0.22.4/cider-nrepl-0.22.4.jar from clojars
Retrieving cider/cider-nrepl/0.25.6/cider-nrepl-0.25.6.pom from clojars
Retrieving cider/cider-nrepl/0.25.6/cider-nrepl-0.25.6.jar from clojars
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by mranderson048.orchard.v0v3v0.dynapath.v0v2v5.dynapath.defaults$eval3516$fn__3517 to method java.net.URLClassLoader.addURL(java.net.URL)
WARNING: Please consider reporting this to the maintainers of mranderson048.orchard.v0v3v0.dynapath.v0v2v5.dynapath.defaults$eval3516$fn__3517
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
nREPL server started on port 53799 on host 127.0.0.1 - nrepl://127.0.0.1:53799
Ive installed the same Leiningen version as you, 2.9.1, it persists. Its a brand new project, with no deps:
(defproject lag291 "0.1.0-SNAPSHOT"
:description "FIXME: write description"
:url "http://example.com/FIXME"
:license {:name "EPL-2.0 OR GPL-2.0-or-later WITH Classpath-exception-2.0"
:url "https://www.eclipse.org/legal/epl-2.0/"}
:dependencies [[org.clojure/clojure "1.10.0"]]
:main ^:skip-aot lag291.core
:target-path "target/%s"
:profiles {:uberjar {:aot :all}})
Sorry for being a noob 😬 but where is this cider-nrepl coming from?
Do you have a user profile in ~/.lein/
maybe? Thinking that might be where the zombie cider-nrepl spawns from.
Also, and this doesn't seem likely to give you an answer, but what does lein deps :tree
show when run from your project directory?
Wow, thanks everyone, and sorry for wasting your time! I inadvertently added something to my Lein profile a few months ago without realising it 🙈
Oh, don't worry about it. I learned stuff from this and am happy you could get it sorted! And I also got re-assured that this jack-in feature is really worth maintaining. It is a way where Calva can contribute to clean up those projects and profiles out there.
Glad to help!
When an evaluation in the Calva REPL throws an Exception it will take more than 30 seconds to throw the exception and return the prompt. Skip from 0:10 -> 0:50
https://user-images.githubusercontent.com/5781355/103618274-56536180-4f38-11eb-9d2c-f357cda16097.mov
Calva - 2.0.146 clj-kondo - 2020.12.120 nREPL - 0.8.3 Clojure - 1.10.1 Java - OpenJDK 64-Bit Server VM 11.0.7+10-LTS Mac, Catalina - 10.15.7 VSCode - November 2020 (version 1.52)
Disabling network fixes the issue, and its responsive again, see #896
Using wireshark, I saw the same DNS requests to clojuredocs-edn.netlify.com, adding this to hosts file fixes it for now: