Good catch, guys.
Interesting that I never noticed this; likely because Pomegranate's
`classloader-hierarchy` function ends up starting its walk from (RT/baseLoader)
(which will be changing to the context classloader shortly):
https://github.com/cemerick/pomegranate/blob/master/src/mai
Colin Jones writes:
Hi Colin,
> Right, this is because nREPL uses clojure.main/repl each time it does
> an evaluation. See http://dev.clojure.org/jira/browse/NREPL-31 for a
> related issue that was addressed by modifying clojure.main/repl.
>
> I'm not sure where a fix for this would belong (nREP
Thank you Colin,
I think, the main problem is nobody has ever tried to write an article
"Class loading in Clojure". If such article existed, it would make life
much easier for many developers.
Regards,
Vladimir
On Monday, December 10, 2012 8:32:36 PM UTC+4, Colin Jones wrote:
>
> Right, this i
Right, this is because nREPL uses clojure.main/repl each time it does an
evaluation. See http://dev.clojure.org/jira/browse/NREPL-31 for a related
issue that was addressed by modifying clojure.main/repl.
I'm not sure where a fix for this would belong (nREPL or clojure.main), but
I went ahead an
Hi,
just found that every interaction with Clojure REPL causes one
more DynamicClassLoader put on the Thread context class loader chain.
Here is how clojure.main/repl beginning looks like:
(let [cl (.getContextClassLoader (Thread/currentThread))]
(.setContextClassLoader (Thread/currentThr
