nrepl

https://github.com/nrepl/nrepl || https://nrepl.org
2021-01-24T01:34:14.000800Z

Hi, I have embedded nrepl in my Java application and need to initialize thread that is used to actually evaluate the expression by setting some session context to thread local variable (this approach cannot be changed). I wrote some simple middleware that utilizes long-lived sessions. In this middleware I just wrap the :code prepending it with initialisation of the session context: (defn inject-session-context  [h]  (fn [{:keys [op session transport code] :as msg}]     (if (and session code)       (let [new-code (str "(do (com.example.nrepl.middleware/set-session-context \"" session "\")"  code ")")]         (h (assoc msg :code new-code)))       (h msg)))) It works, but in combination with cider-nrepl middleware disrupts debugging functionality. The only alternative solution (w/o nrepl source modification) that I found so far would be to check thread name, which has format "NREPL-session uuid" when theread local is accessed (it is necessary only in dev. mode), but I'd like to avoid this fragile approach. Maybe there is a better option? Thank you.

bozhidar 2021-01-24T19:29:02.006400Z

Btw, what exactly are you aiming to achieve with this middleware? That's not clear to me, so I wanted to clarify this before discussing any potential options/solutions.

2021-01-26T12:41:15.010900Z

The code that is called directly or indirectly in evaluated expression needs access to session context stored in thread local variable. Session context stores such information as long running hibernate session, login data. Currently as a workaround I just modified evaluate in interruptible-eval:

2021-01-26T12:41:30.011100Z

:eval (let [eval-fn (if eval (find-var (symbol eval)) (com.example.clojure.nrepl.callbacks/gb-eval-fn session-id))]

2021-01-26T12:43:22.011300Z

Where gb-eval-fn just initialises session context if it is empty for this session, sets corresponding thread local and performs eval (defn gb-eval-fn  [session-id]  (fn [code]  (do    (when session-id    (set-session-context session-id))    (eval code))))

2021-01-26T12:45:37.011600Z

I hope I answered the question. Basically there is big legacy java code base that is called by clojure code and it relies on the presence of the session context in the thread local var

2021-01-31T15:47:40.014900Z

Sorry for pinging @bozhidar , will do this only once - not sure how threads notification work. Would appreciate your feedback whenever you have time

bozhidar 2021-02-01T08:21:55.015100Z

No worries. Can you open a discussion on the subject https://github.com/nrepl/nrepl/discussions so it'd be less likely that I'll forget about this.

bozhidar 2021-02-01T08:24:49.015300Z

Generally it seems to me it'd be preferable for you to modify the session but inserting some middleware before eval instead of modifying eval directly, but I might be missing something. I'm also wondering if this https://github.com/nrepl/nrepl/pull/214 might be something that can be helpful in your case

bozhidar 2021-02-01T08:25:35.015600Z

With a configurable thread factory you might be able to move this init logic to it (I presume).

odie 2021-01-24T10:05:26.004500Z

Hi all, I updated cider & friends after some time away from clojure. I found that I’m repeatedly getting unhandled exceptions like this:

ERROR: Unhandled REPL handler exception processing message {:op eldoc, ...}
Here’s the startup cmd reported by cider:
;;  Startup: /usr/local/bin/clojure -Sdeps '{:deps {nrepl/nrepl {:mvn/version "0.8.3"} refactor-nrepl {:mvn/version "2.5.0"} cider/cider-nrepl {:mvn/version "0.25.7"}}}' -m nrepl.cmdline --middleware '["refactor-nrepl.middleware/wrap-refactor","cider.nrepl/cider-middleware"]'
Am I missing something really obvious here?

dpsutton 2021-01-24T17:58:24.005400Z

Check #cider Someone was just in there reporting this. Hopefully there’s a ticket linked as well

bozhidar 2021-01-24T19:26:14.006300Z

@dpsutton @odie We already fixed this on Orchard's master (https://github.com/clojure-emacs/orchard/commit/e3de281fa731ee81c3a012200c0c94b4e2cecded), even though we're not quite sure how something like this might be happening and why it's affecting only some people.