Do you guys know if I assign ::http/interceptors [] , even it's an empty vector, then when there is an error, the only message I got is : Internal server error : no response. if I don't have ::http/interceptors, it returns a nice stack trace for me to debug. What is the right way to provide default interceptors on current service ?

https://www.youtube.com/watch?v=_Cf-STRvFy8 Great talk, cannot wait to see pedestal chain on clojurescript !

@nxqd Just update conj the ::http/interceptors after you put called the default-interceptors. (Without the :http/interceptors since if default-interceptors sees that map key it won't do anything.)

@rauh thanks.

Is content negotiation + coercion a manual practice like described in http://pedestal.io/guides/hello-world-content-types or is there some provided sane defaults in Pedestal?

@borkdude, AFAIK that’s how it’s done.

Hi all, is this the right place for Vase-related questions or should I take it to #vase?

@crimeminister not sure who’s using #vase. I think this is the right place for now.

Cool!

Am wondering about the possibility of using specs defined in an external library; getting Unable to resolve spec: :com.example/some-spec when I try. Anyone know if this is supported?

I should go spelunking, but figured it couldn't hurt to ask first ;)

So I assume you mean specs that are registered via s/def, correct?

Yes

If so then I don’t see why that wouldn’t work. I imagine you need to require the appropriate namespaces before reading in the vase descriptor(s)

Cool, I will give it another whirl, thank you

That worked, much appreciated

np, glad to help!

Am wondering: would it make sense to provide a list of namespaces to require as part of the Vase edn config?

I think that’s app-specific. You normally won’t need much more than what’s defined in the service.clj file which is created by the Vase lein template.

Remember specs are registered globally. They’re actually stored in an atom defined in the spec ns.

They get registered when the ns they are defined in is evaluated

This means that specs defined in your descriptor(s) are also available elsewhere in your Vase-enabled app

Agreed, just thinking that on occasion it might be useful to specify a namespace to evaluate as part of Vase config so the spec can be used by a #vase/validate without a having to touch server/service.clj. Minor thing though.

Didn't realize that was how spec was implemented; interesting

Oh, I see what you are asking for

I have several apps all using shared specs in a library, just pulling those into the Vase microservice I am playing with

Hmm, IMO the convenience does not outweigh the trouble of implementing and supporting such a feature.

Quite likely, and not sure how common this pattern is anyways

No doubt others will chime in if it might be useful ;)

very true!

Does anyone got an example how to load resources from a jar? I tried this:

(def font-awesome-webjars-resource-path “META-INF/resources/webjars/font-awesome/4.7.0”)
…
service-map {::http/routes routes
                            ::http/type   :jetty
                            ::http/join?  false
                            ::http/resource-path "/public"
                            ;; Doesn't work yet
                            ::http/default-interceptors [(middlewares/resource
                                                          font-awesome-webjars-resource-path)
                                                         ]
                            ::http/port port}

I think you might want to look at , specifically (io/resource …)

Am in transit, otherwise would post a more substantial example, sorry