ring-swagger & compojure-api
ikitommi 2018-08-17T10:12:44.000100Z

thanks and great to hear you got it working! many people involved in creating the lib.

ikitommi 2018-08-17T10:13:03.000100Z

and not sure what you mean with “swagger.json never actually gets generated”.

ikitommi 2018-08-21T16:11:52.000100Z

oh, yes, c-api generates that when requested

vuuvi 2018-08-21T17:41:31.000100Z

yeah I didn’t understand that at all, it might be helpful to explain that to users when they’re just starting out so they aren’t searching for something that will never exist 😄

ericstewart 2018-08-17T13:55:50.000100Z

hunting down a compojure-api + swagger question. I want to support query string parameters such as ?filter[user]=1&filter[other]=3 that decompose into a clojure map {:filter {:user 1 :other 3}} (and of course have swagger nicely doc this. I haven't been able to make this work, even though I have seen some older issues pointing to supporting this, such as https://github.com/metosin/compojure-api/issues/4. I'm using compojure-api 2.0.0-alpha23 and spec for coercion. Is this still supported?

ericstewart 2018-08-17T14:41:42.000100Z

looks like wrap-nested-params, part of compojure-api's default middleware stack, should handle this but having trouble triggering it

ericstewart 2018-08-17T15:23:57.000100Z

ok.. learning more and more as I dig. turns out that I was looking at the requests :query-params only. After looking at the code for wrap-nested-params I do see the nested map structure in the requests :params (the merged parameters map). So the challenge move to providing coercion/validation and swagger docs

ikitommi 2018-08-17T16:02:49.000100Z

@ericstewart hmm. It would be good if they were copied into :query-params. Could the middleware be rewritten into compojure.api.middleware with that? Or the original changed in ring.

ikitommi 2018-08-17T16:04:42.000100Z

Another option would be to add the :params restucturing. But can't emit swagger docs as we wouldn't know which type they are.

ericstewart 2018-08-17T16:34:26.000100Z

right. I got swagger to pick up the keys however by using :query-params (s/keys :req-un ["filter[user_id]", "filter[other]"]) but I don't get value coercion (left as strings). I am using resource. Would be nice if they were copied into :query-params to take advantage of coercion there. I think I have found a different design workaround that won't require nested params, but would like to help get these in a better state for future needs.

jdt 2018-08-17T18:18:44.000100Z

Hi all. I'm a tiny bit stumped. I have a compojure-api 2.0.0-alpha23 app. I'm trying to return this response {:status 200, :body #object[org.projectodd.wunderboss.web.undertow.async.UndertowHttpChannel 0x7ee55dc7 "org.projectodd.wunderboss.web.undertow.async.UndertowHttpChannel@7ee55dc7"], :headers {"Content-Type" "text/event-stream; charset=utf-8"}} From the result of immutant.web.sse/as-channel (http://immutant.org/documentation/2.0.0-beta2/apidoc/immutant.web.sse.html), but I'm getting hung up in processing after I exit the GET route with the response, and getting an exception (which I'll post in snippet next).

jdt 2018-08-20T14:43:46.000100Z

Hi Tommi, so upgrading various muuntaja and compojure-api libraries as discussed in the main thread has fixed my encoding exception, and I appear to be returning the above response from the server. However the http client is just hanging on a GET from the response. In testing an identical get and identical server response in a plain immutant web app without compojure api it works fine (using {:as :stream} in the clj-http client request). But it isn't working in the compojure-api scenario. Is there some special streaming response I need to specify with compojure-api?

jdt 2018-08-20T14:52:38.000100Z

compojure-api streaming failure non-compojure-api works, closer but not working yet.

jdt 2018-08-20T15:10:26.000100Z

I'm wondering if it isn't something about the client Content-Type headers including application/json, and that being a mismatch for the the headers specifed in the sse-channel response ("text/event-stream" - as above).

jdt 2018-08-20T15:12:04.000100Z

(not shown in snippet, will try without).

jdt 2018-08-20T15:18:09.000100Z

Yeah, client inclusion of client content type specifications makes no difference, the GET hangs on the sse-channel response via compojure-api. Not sure how to debug the up-stack activities of compojure-api after I return the value, suggestions?

jdt 2018-08-20T15:22:44.000100Z

curl says "empty reply from server".

jdt 2018-08-21T11:56:02.000100Z

I'm still struggling with this. I'm guessing it isn't compojure-api, though the fact remains that while my endpoint is invoked and the response returned from my GET form, the client can never read the response. I built a standalone software project with all the same dependencies to also return an sse channel response, and that worked, so clearly compojure-api works with the as-channel response. But in my production app the clients, any client, can't read the response. They connect, but not enough gets flushed for them to read the response (e.g. :status), and so they hang. Checking stale build artifacts now, every so often lein does stuff wrong, we'll see what happens.

jdt 2018-08-21T13:23:29.000100Z

I have a workaround. If I transmit, from the server, any text to the SSE channel, then the client gets a response and all things work well. As this is an SSE channel I can just send a comment. But in the standalone app I tested with the same dependencies it was not necessary, and should not be necessary. Somehow there seems to be something conditional going on up the stack from the GET return that decides what gets flushed and when. It's returning a chunked response, perhaps it should not be returning a chunked response. Still a mystery but I have a workaround for now.

jdt 2018-08-17T18:18:59.000100Z

jdt 2018-08-17T18:19:19.000200Z

Any tips?

jdt 2018-08-17T18:19:51.000100Z

Muuntaja 0.5.0

jdt 2018-08-17T18:22:07.000100Z

The sweet/api is :coercion :spec, and the route responses are declared as 200 {:description "Success. A stream is returned." :schema any?}

ikitommi 2018-08-17T18:22:59.000100Z

@dave.tenny, could you try Muuntaja 0.6.0-alpha3?

jdt 2018-08-17T18:23:07.000100Z

will do

ikitommi 2018-08-17T18:24:28.000100Z

if the response has Content-Type set, the body should not be encoded

jdt 2018-08-17T18:25:11.000100Z

The map above is the exact thing I'm returning

jdt 2018-08-17T18:25:28.000100Z

Perhaps the Content-Type needs to be pushed up in the map?

jdt 2018-08-17T18:26:49.000100Z

Hmmm, thta new Muuntaga lib is giving me Exception in thread "main" java.lang.ExceptionInInitializerError when compiling some modules

jdt 2018-08-17T18:27:35.000100Z

Will try a full project rebuild, I have lein monolith submodules and such.

ikitommi 2018-08-17T18:33:17.000200Z

your response seems correct, but needs the 0.6.0-alpha3. before that the rule was: if there is a response body defined (:return or :responses), always encode the body.

ikitommi 2018-08-17T18:33:48.000100Z

the 0.6.0 should be out before next thu

jdt 2018-08-17T18:34:10.000100Z

ok, having build problems, probably need to make other dependency changes

jdt 2018-08-17T18:34:12.000100Z

Exception in thread "main" java.io.FileNotFoundException: Could not locate muuntaja/format/msgpack__init.class or muuntaja/format/msgpack.clj on classpath.,

jdt 2018-08-17T18:34:37.000100Z

(only since trying to add 0.6.0-alpha3)

jdt 2018-08-17T18:34:52.000100Z

will try some more

jdt 2018-08-17T18:35:32.000100Z

might take a while, back later

ikitommi 2018-08-17T18:40:13.000100Z

I think you need to have [metosin/muuntaja-msgpack "0.6.0-alpha3"] as dependency.

jdt 2018-08-20T12:55:27.000100Z

Hmmm, this causes existing code to break. Apparently muuntaja.format.msgpack/with-msgpack-format no longer exists and I have code that uses it in my api configuration map: e.g. :formats (m/create (-> m/default-options (msgpack-format/with-msgpack-format)))

ikitommi 2018-08-20T13:02:09.000100Z

@jdt the with-* were removed, there is muuntaja.core/install helper to add the modules. The changelogs should show how to use it

ikitommi 2018-08-17T18:42:09.000100Z

There was a discussion should yaml & msgpack be included in the default profile, and they were removed. Definetely need a good migration documentation.

jdt 2018-08-20T12:40:06.000100Z

Please don't put yaml back in as a default. My company explicitly removed yaml support because of the potential for yaml bomb denial of service attacks, as the yaml parser use by ring/swagger definitey succumbs to this problem.

jdt 2018-08-20T12:41:02.000100Z

If you add it back in as a default, since we now rely on that non-yaml-default behavior having upgraded to compojure-api 2.0.0, then it reintroduces the security risk.

ikitommi 2018-08-20T13:03:36.000100Z

not putting them back