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

Oh, I didn't know. I thought it was only recently announced.

3.0 is RC, but 2.x has been here for a while I think

Oh, sorry, off-by-one error.

common mistake 🙂

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]

@lsnape did you add to the protocol for yada & functions?

No, I don’t think I need to because get-handler is returning a #yada.handler.Handler right?

Let’s say that this is get-handler:

(defn get-handler
  [request]
  (yada “pong”))

The first argument to listener shouldn't be wrapped in fn

I don't really understand what you're trying to achieve

I have my own way of matching the yada handler from the uri in the request

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.

You have to extend-protocol for clojure.lang.Fn for that to work.

https://github.com/juxt/yada/blob/51e73aaa91578abe02db9cf812bbaf9b911efa5d/src/yada/handler.clj#L162 also, it seeems that handle-request is 3-arity.

@lsnape what version of yada are you using :thinking_face: ?

@dominicm I’m using version 1.2.1

I’m calling handle-request with 3 args above

derp, yes

Sorry needless threading is a terrible habit of mine

Anyone tried to use Yada with Integrant?

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"

When I do (halt) and then try to do any of the integrant.repl commands after

kardan: I’m using yada with integrant. I have seen an ‘event executor terminated’ message, but didn’t attribute it to integrant.

(realise this might been the wrong chat for this)

What makes you think that it’s integrant?

dominicm, just looking through the handler ns to see if I can find any clues!

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

Thanks

Nope. I assure you the above works out of the box 🙂

Good luck kardan!

This returns a yada handler: (as-handler (fn [ctx]))

So it is

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))

But I'm requesting html, but getting the bytebuffer back

So handle-request returns a deferred. I’ve inspected (dereffed) it and it looks OK

@lsnape the problem is that you're returning a ring request string, and yada is expecting the return value of your response function here.

I'm not sure on the correct implementation of course 🙂

@lsnape Not sure what protocol is matching, but if you do:

(extend-protocol HandlerCoercion
  clojure.lang.Fn
  (as-handler [this] this))

Or rather, you can return a deferred & it's happy

oh, check the keys in ctx

@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
    {}))

Required the extend-protocol above ^^

Thanks @dominicm . I’ll try that out

Can't say I 100% understand why passing a fn directly works yet

https://github.com/juxt/yada/blob/51e73aaa91578abe02db9cf812bbaf9b911efa5d/src/yada/handler.clj#L267 I have a feeling it's matching this.

Yep, it's matching on that. And (handler (fn [])) isn't what we want

Looking at the source for how protocols are implemented, it makes sense that functions match Object, even though isa? is false for fns.

So yeah, you need to implement functions for the protocol ^^ and then call handle-request correctly

Now I may sleep 😄

Ah yes that makes sense now. Works perfectly my end - thanks for your help! 😴