juxt

rgm 2019-01-09T02:50:14.009300Z

I have an esoteric thing going on with pack/onejar and I’m hoping for some guidance on where to even deal with it… the situation:

rgm 2019-01-09T02:50:36.009900Z

- I’m packing up an uberjar with onejar (it’s the one I could get working; no real preference,

rgm 2019-01-09T02:50:59.010400Z

- I have a ring handler using (wrap-resource "public")

rgm 2019-01-09T02:52:26.011200Z

it seems that my static file delivery blows up because of a missing :onejar method for ring.util.response/resource-data

rgm 2019-01-09T02:56:10.012700Z

my java-fu is insufficient to figure out the method implementation. I don’t think this is really a juxt/pack problem, but I’m hoping for some guidance where I might document this or help other people out with getting over the hump

dominicm 2019-01-09T06:29:07.015600Z

Make sure you're on master. This might have been broken recently. The readme is out of date. Any clues about what resource-data does? I'm guessing it is looking at the URL in some way. Capsule would avoid the problem if so.

rgm 2019-01-09T21:00:24.017800Z

@dominicm resource-data seems to do the work of figuring out content-type, last-modified, content-length headers so Ring can stuff them into the response. Ring provides :file and :jar implementations, but it seems onejar gives back URLs of the form onejar://.... See also https://github.com/ring-clojure/ring/blob/1.7.0/ring-core/src/ring/util/response.clj#L241-L242

rgm 2019-01-09T21:00:48.018400Z

pretty sure this isn’t pack’s problem. I’ll give capsule a go

dominicm 2019-01-09T21:19:41.019600Z

@rgm I reckon the jar implementation would work for what onejar has given you, based on a cursory look.

rgm 2019-01-09T21:23:37.020100Z

maybe so … I bailed out and used depstar to make a deadline but I’ll circle back.

dominicm 2019-01-09T21:31:08.020400Z

Hehe 😊