Clojurians Log v2
ring-swagger
thanks and great to hear you got it working! many people involved in creating the lib.
and not sure what you mean with “swagger.json never actually gets generated”.
oh, yes, c-api generates that when requested
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 😄
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?
looks like wrap-nested-params, part of compojure-api's default middleware stack, should handle this but having trouble triggering it
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
@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.
Another option would be to add the :params restucturing. But can't emit swagger docs as we wouldn't know which type they are.
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.
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).
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?
compojure-api streaming failure non-compojure-api works, closer but not working yet.
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).
(not shown in snippet, will try without).
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?
curl says "empty reply from server".
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.
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.
Any tips?
Muuntaja 0.5.0
The sweet/api is :coercion :spec, and the route responses are declared as 200 {:description "Success. A stream is returned." :schema any?}
@dave.tenny, could you try Muuntaja 0.6.0-alpha3?
will do
if the response has Content-Type set, the body should not be encoded
The map above is the exact thing I'm returning
Perhaps the Content-Type needs to be pushed up in the map?
Hmmm, thta new Muuntaga lib is giving me Exception in thread "main" java.lang.ExceptionInInitializerError when compiling some modules
Will try a full project rebuild, I have lein monolith submodules and such.
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.
the 0.6.0 should be out before next thu
ok, having build problems, probably need to make other dependency changes
Exception in thread "main" java.io.FileNotFoundException: Could not locate muuntaja/format/msgpack__init.class or muuntaja/format/msgpack.clj on classpath.,
(only since trying to add 0.6.0-alpha3)
will try some more
might take a while, back later
I think you need to have [metosin/muuntaja-msgpack "0.6.0-alpha3"] as dependency.
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)))
@jdt the with-* were removed, there is muuntaja.core/install helper to add the modules. The changelogs should show how to use it
There was a discussion should yaml & msgpack be included in the default profile, and they were removed. Definetely need a good migration documentation.
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.
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.
not putting them back