This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-03-28
Channels
- # beginners (8)
- # boot (49)
- # cljs-dev (29)
- # cljsrn (9)
- # clojure (238)
- # clojure-dev (3)
- # clojure-gamedev (1)
- # clojure-italy (7)
- # clojure-norway (11)
- # clojure-russia (39)
- # clojure-sanfrancisco (3)
- # clojure-spec (116)
- # clojure-sweden (2)
- # clojure-uk (53)
- # clojurescript (90)
- # cursive (13)
- # datomic (12)
- # defnpodcast (2)
- # dirac (1)
- # emacs (11)
- # figwheel (2)
- # hoplon (15)
- # jobs (3)
- # jobs-discuss (48)
- # keechma (1)
- # klipse (4)
- # leiningen (16)
- # luminus (4)
- # lumo (49)
- # mount (10)
- # off-topic (1)
- # om (13)
- # onyx (15)
- # pedestal (67)
- # perun (1)
- # planck (16)
- # powderkeg (33)
- # proton (1)
- # protorepl (2)
- # re-frame (16)
- # reagent (4)
- # ring (9)
- # ring-swagger (10)
- # rum (5)
- # slack-help (1)
- # spacemacs (1)
- # uncomplicate (15)
- # untangled (19)
- # yada (58)
Sorry if this conversation has already happened, but has the Swagger (OpenAPI) 2.0 API inspired any changes in yada?
yada already supports OpenAPI 2.0. Is there something missing?
Afk. Will have to check later
Yes. I think yada does NOT support 1.x
Iām going wrong here somewhere:
(yada/listener (fn [{:keys [request] :as ctx}]
(-> (get-handler request)
(handle-request request ctx)))
{:port port})
Where get-handler
returns a yada handler. The error Iām getting is:
Cannot JSON encode object of class: class java.nio.HeapByteBuffer: java.nio.HeapByteBuffer[pos=0 lim=4 cap=4]
No, I donāt think I need to because get-handler
is returning a #yada.handler.Handler
right?
listener
does accept a function as its first argument, which is needed for the use case where something other than bidi or yada decides which resource handles the request.
I thought it called as-handler on it? Which when I last tried didn't support that :thinking_face:
https://github.com/juxt/yada/blob/51e73aaa91578abe02db9cf812bbaf9b911efa5d/src/yada/handler.clj#L260-L268 there's a few others.
https://github.com/juxt/yada/blob/51e73aaa91578abe02db9cf812bbaf9b911efa5d/src/yada/handler.clj#L162 also, it seeems that handle-request is 3-arity.
I seem to run into some issue with Aleph "SEVERE: Failed to submit a listener notification task. Event loop shut down? java.util.concurrent.RejectedExecutionException: event executor terminated"
kardan: Iām using yada with integrant. I have seen an āevent executor terminatedā message, but didnāt attribute it to integrant.
lsnape I'm not certain how you're calling yada/listener. Are you sure you've no code like:
(extend-protocol HandlerCoercion
clojure.lang.Fn
(as-handler [this] this))
Iām not sure what the problem is at the moment. But as you imply, I should try to limit the options
Anyway, I can reproduce with:
(fn [{:keys [request] :as ctx}]
(yada.handler/handle-request
(yada/resource {:methods {:get {:response (fn [ctx] {:from-resource :foo})}}})
request
ctx))
@lsnape the problem is that you're returning a ring request string, and yada is expecting the return value of your response function here.
@lsnape Not sure what protocol is matching, but if you do:
(extend-protocol HandlerCoercion
clojure.lang.Fn
(as-handler [this] this))
the world is happy :thinking_face:@lsnape This works:
(fn [req]
(yada.handler/handle-request
(yada/handler
(yada/resource
{:methods {:get
{:produces "text/html"
:response (fn [ctx] {:from-resource :foo})}}}))
req
{}))
https://github.com/juxt/yada/blob/51e73aaa91578abe02db9cf812bbaf9b911efa5d/src/yada/handler.clj#L267 I have a feeling it's matching this.
Looking at the source for how protocols are implemented, it makes sense that functions match Object, even though isa?
is false for fns.