Does anyone have an example of injecting component dependencies into a service handler?

In ring I used to inject everything in a server component and close over the dependencies when making the routes.

Not sure that’s the best approach with pedestal since it seems like a good use-case for an interceptor…?

@jfntn Unfortunately this guide is still pending http://pedestal.io/guides/pedestal-component-handlers-and-dependencies but I think your approach will work

Yes I saw that, which is why I asked here 🙂

You can have an interceptor which assoc’s the pedestal component to the context allowing downstream interceptors to pull the requisite dependencies off it

Some of the links specified here are instructive: http://pedestal.io/guides/pedestal-with-component#_in_the_wild

I’m also working on an alternative implementation for this. I hope to release it soon and update the guide

Ah I missed those links, thanks

Is that the patter you were referring to @ddeaguiar https://github.com/pointslope/elements/blob/master/src/pointslope/elements/pedestal.clj#L95 ?

So I’m now preferring the approach outlined here: https://github.com/ddeaguiar/component-pedestal/tree/route-provider

again this is a work in progress but the idea is that components provide routes. Component-specific routes include interceptors which provide access to dependencies

Be aware that the usage described there demonstrates a handler accessing dependencies but I’m going to change that to be an interceptor instead

by making dependencies accessible via the Context, you gain dynamic dependency mgmt which makes testing easier

imo anyways

But I’ve used the implementation demonstrated in the Elements project with success as well

FYI, the code in the master branch of the component-pedestal repo was really experimental. The implementation is cute but I don’t think it’s a good idea to decouple components from their usage in interceptors/handlers.

That’s nice, had a similar RouteProvider protocol with our ring version and I liked it, but I’m not sure how if I like having per-route component injectors, I think I’d rather always add the union of all deps to the context and forget about it

Then the approach implemented by Elements, which is based on Stuart Sierra’s component-pedestal exploration, is for you.

Looks good to me, thanks @ddeaguiar !

np 🙂

What is the recommended way of handling parse failures from io.pedestal.http.body-params/body-params? i.e. When a request contains invalid JSON causing Cheshire to fail parsing it. I see two options: 1. Write my own version of the body-params interceptor that wraps the call to parse-content-type in a try/catch. 2. Add an error interceptor to the interceptor chain that looks for parse failure exceptions and attaches a :status 400 to the :response. I don't really like option 2 because it forces you to have to remember that if you use the body-params interceptor you must also use the error interceptor. I'm just wondering what you guys typically do.