Closed daveray closed 10 years ago
Yeah that class path looks like the problem. I retrieve it with a straightforward System/getProperty
. I don't understand why it's different from the one clojure is seemingly using.
My guess is that I'm starting the nrepl server in the context of the webapp so it gets the webapp's classloader so all commands through there work fine. The java.class.path
property only reflects the JVM's startup classpath which is why it's just gradle-wrapper.jar
.
Is there a way I can tell fireplace "hey, this is the classpath" to try fiddling with it to see what I can get working?
Stick the connection in a temp var and you can just assign ._path
on it. Leading colon is mandatory.
Is there an easy way to get the runtime class path?
Thanks. I replaced java.class.path
with this and it works now, both with my web app and a simple Lein project:
(let [cl (.getClassLoader clojure.lang.RT)]
(if (instance? java.net.URLClassLoader cl)
(->> cl
.getURLs
(map #(.getFile ^java.net.URL %))
(clojure.string/join (System/getProperty "path.separator")))
(System/getProperty "java.class.path")))
There are probably other cases where this would break down.
Wrap this up in a pull request and I'll merge.
We now use the classpath nREPL operator if available, which I think by and large solves this.
I have a project where evaluation, loading code, etc all works fine, but navigating to source (for symbols, local namespaces, and jar namespaces, and alternates) doesn't work. I just get a message like:
Couldn't find com/netflix/social/entity/profile_test.clj in class path
I'm guessing the fact that this I'm connected to nrepl in a (local) Jetty server is confusing things. What can I do to figure out where the disconnect is between the classpath on the server and whatever fireplace thinks the classpath is?
When I look in
fireplace_nrepl_sessions
I see_path
is just':.../gradle/wrapper/gradle-wrapper.jar'
. Maybe that's it since that's technically the top-level classpath of the JVM.