This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # 100-days-of-code (3)
- # beginners (80)
- # cider (53)
- # cljdoc (9)
- # cljs-dev (66)
- # cljsrn (6)
- # clojure (108)
- # clojure-austin (5)
- # clojure-dusseldorf (1)
- # clojure-italy (9)
- # clojure-losangeles (2)
- # clojure-nl (4)
- # clojure-spec (40)
- # clojure-uk (46)
- # clojurescript (60)
- # cursive (119)
- # datomic (28)
- # emacs (10)
- # events (1)
- # figwheel-main (21)
- # fulcro (16)
- # hyperfiddle (10)
- # immutant (2)
- # leiningen (1)
- # liberator (5)
- # nyc (1)
- # off-topic (36)
- # onyx (4)
- # pedestal (52)
- # portkey (5)
- # re-frame (11)
- # reagent (11)
- # shadow-cljs (46)
- # sql (1)
- # unrepl (2)
coerce-body just seems to get skipped over no matter where I put it in the default interceptors stack
If you paste a relevant snippet I might be able to help more — it seems like it should work if it is at the top of the stack, after all the default interceptors. I’ve done this in my own experiments with minimal fuss.
https://gist.github.com/deadghost/bee98e65d29bf242c7428d880680470d default stack snippet
Hm, I missed the default stack issue. All I can suggest is, try putting an
enter interceptor there as well that prints the interceptor queue? Or perhaps some other interceptor there is calling
terminate early so your interceptor is never running?
::http/routes have any effect on the router there? I vaguely remember that all this configuration is only needed to create the default interceptor stack, otherwise you’re on your own.
I suspect that the issue is the way you create your default interceptor/servlet stack.
Looking at https://github.com/pedestal/pedestal/blob/master/service/src/io/pedestal/http.clj#L254, it seems that some of those interceptors are wrapped with
interceptor, some are passed extra arguments, etc. It’s not clear in your server snippet what are you passing in.
I’m not an expert in pedestal and this part of the code seems quite hairy to me, so I can’t help any further there — other than to suggest that it might make sense to adopt the official way to do things?
😅 my recent stupid mistake was I wasn't aware that servlet-interceptor terminates chain execution when it encounters valid ring-response in context's
:response, the executors removes the rest of the
:queue from the context and starts processing
:leave stages. I should have properly read servlet-interceptor reference here http://pedestal.io/reference/servlet-interceptor
@mavbozo my current issue is I have an
authentication interceptor that does attach a non-nil
:response but it doesn't appear to short-circuit
@deadghost woops.. I made mistake above. by reading the servlet-interceptor codes I found that servlet-interceptor terminates when it encounters valid ring-response in the context's
:response. I've edited my message above.
is there any compelling reason to keep body params named after their content type? I’m tempted to add an interceptor that will just rename everything to
:body-params so that I can have an API that will serve both edn and json requests through the same code
@stathissideris if you are interested in 3rd party addons, there is a pedestal-compatible interceptor doing just that in Muuntaja library,
Thanks, I’m interested in 3rd party party interceptors, even if it’s just as an example!
@stathissideris the Pedestal philosophy around this sort of thing is:
If something is separate, keep it separate. If something can be customized via an interceptor, keep the base code as basic as possible.
So adding an interceptor which does what you’ve stated is perfectly acceptable. There has been some back-and-forth internally as to whether such helpers should be included in Pedestal core. As of now they won’t.
@ddeaguiar thanks, that makes sense, it’s trivial to add a basic interceptor to achieve it anyway. I like the design decision. I just wanted to make sure I wasn’t missing something