Fork me on GitHub

@nxqd absolutely, i’ve been tearing github apart looking for an example


@mtnygard thanks, that should do, i’ll take a look back at earlier posts as well. thanks


@mtnygard Thanks, so it's definitely worth diving into Vase to provide an API for an existing application?


@gerstree I think so, but it will depend on how much logic is in your application. Vase is really meant to be a quick, easy way to shuttle data from HTTP into and out of Datomic. If you need more logic than Vase provides, you can use custom interceptors. The descriptor will start to get unwieldy when the chains are long.


One thing I’ve done is use Vase to describe a bunch of the “dumb” routes that pump data back and forth, but then use hand-written routes to handle the more interesting cases.


(I’ll post a gist with some bits that might come in handy for that)


I don’t have a logging setup in my project yet, if I want pedestal to print debug info I’ll have to configure logback with an xml file is that correct?


apps generated through the lein templates will have a logback config


thanks, will take a look


Ah that worked, thanks @ddeaguiar


I guess I can’t ignore jvm logging libraries anymore :0


Yeah. I little logback knowledge goes a long way 🙂


This is a sidetrack, but I’ve been logging everything as edn maps using pr-str for a while and it’s been really useful, are there any reasons why you would NOT want a custom logback appender to do that?


I’ve not found a need to implement a custom appender thus far but I suppose it depends on the need


not familiar with that, does it parse the lines into data structures to make it easier to navigate them?


well it at least pretty prints them


you can expand/collapse lines


and you can query your logs


Interesting, do you think you could do something like that before writing to the file or there would be too much overhead?


@jfntn not sure I follow


Ha sorry missing some context here. In the previous rev of our backend we wrote a very simple logger that’d take a single clojure map and write it as edn. What was great about it was that consuming the logs was simple as something like (map edn/read-string (line-seq "app.log")) and then you can filter etc. What wasn’t so great was that our app logs were special snowflakes and we had to handle them separately from the logs printed by all our dependencies. I didn’t know of lnav but what I’m wondering now is could we apply the same kind of processing where a regexp gets parsed into a map, but do it before writing and turn all our libraries’ logs into edn maps.


@jfntn lnav supports different formats and provides many predefined ones. It uses the format that matches the current log file.


you can get as fancy as you like


you can also configure it to work with Papertrail although I’ve not tried that


I can't quite figure out why if I include io.pedestal.http/dev-interceptors , I always get a 403 Forbidden with any of my routes even though I have set ::http/allowed-origins to (constantly true). Any ideas why this would be happening?


The problematic interceptor is io.pedestal.http.cors/dev-allow-origin. Though, all it is doing is setting the request origin to an empty string if it doesn't exist. I don't see how that would affect the (constantly true) function.


The interceptors in the service map that causes the 403 are these:

#Interceptor{:name :io.pedestal.http.impl.servlet-interceptor/exception-debug}
#Interceptor{:name :io.pedestal.http.cors/dev-allow-origin}
#Interceptor{:name :io.pedestal.http/log-request}
#Interceptor{:name :io.pedestal.http.cors/allow-origin}
#Interceptor{:name :io.pedestal.http/not-found}
#Interceptor{:name :io.pedestal.http.ring-middlewares/content-type-interceptor}
#Interceptor{:name :io.pedestal.http.route/query-params}
#Interceptor{:name :io.pedestal.http.route/method-param}
#Interceptor{:name :io.pedestal.http.route/router}
If I remove #Interceptor{:name :io.pedestal.http.cors/dev-allow-origin} everything works A-OK.


I figured it out... I called default-interceptors before I overrode the ::http/allow-origins key.


boo cant destructure …. [{:keys parama paramb} (:params request)] wont work as params are strings…..


@bherrmann you can use :strs instead of :keys


jfntn: wow ! I just learn something new today 😄