This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (11)
- # boot (121)
- # bristol-clojurians (3)
- # cider (5)
- # cljs-dev (45)
- # clojure (122)
- # clojure-conj (3)
- # clojure-germany (1)
- # clojure-japan (9)
- # clojure-russia (48)
- # clojurescript (129)
- # community-development (2)
- # cursive (17)
- # datomic (11)
- # editors-rus (3)
- # events (2)
- # funcool (32)
- # ldnclj (22)
- # om (110)
- # onyx (15)
- # re-frame (2)
so it gets on to the classpath because it is in a directory specified in
serve task (which is delegating to
ring.util.response/resource-response) is seeing the version on disk instead of the updated fileset one
(ring.util.response/resource-response "index.html") in this case is serving
<resource-path>/index.html, not the updated fileset one
when you do
io/resource you're asking a classloader to resolve the path and return a handle to a thing on its classpath
different pods have different default classloaders, so they can have different classpaths, too
so the stuff that happens to the fileset happens in the "default classloader" right?
ok so if i stick
(io/resource "index.html") in the middle of a task that comes after modifications+fileset commit, it should get the updated one from the fileset, right?
so btw, if a file foo is in resource-paths, doing
(io/resource "foo") and
(tmp-file (first (by-name ["foo"] (input-files fileset)))) is kinda sorta functionally the same thing?
the classpath is the best way to get the thing because it abstracts away the mechanics of the actual resource sotrage
so "foo" might be coming from a jar file, from the internet, from a local directory, you don't need to know or care
so you can have this environment where all the resources are accessible via the same uniform interface
i think the reason i'm serving the filesystem version of "index.html" is that boot-http creates a server with handlers in a
delay in the let bindings prior to
with-pre-wrap, and then dereferences it inside
not quite sure how
delay works but I wonder if switching to an atom instead and defining the server inside
with-pre-wrap would make the resource call point to the fileset's versions
:resource-root below it sets an optional prefix to the path that resources try to resolve
the bread and butter is here: https://github.com/pandeiro/boot-http/blob/master/src/pandeiro/boot_http/impl.clj#L84-L104
so you're saying that you never see any files change when you access them via jetty, even if they've changed in the classpath?
not sure i have any other examples of a file that exists in resource-path but gets updated in pipeline and served
(io/resource "index.html") inside task pipeline and inside the
serve handler return different URL paths
the latter is identical to the path that's returned on the resource before it's modified in the pipeline
did you put a task between build and serve that checks if the changed file is in the fileset etc?
@pandeiro: have you tried making a task that just tries looking it up with
io/resource instead of through fileset?
ah ok. I thought you looked at the file through the fileset instead of looking it up with
It seems like maybe the resources handler in serve is 'binding' to an earlier fileset 'context', eg when the NS is required
@pandeiro: going even more low-level you could look at the
(:dirs fileset) and check if your file is properly linked there. as far as I understand these dirs will not change during a boot invocation so if it is there the only explanation would be that there’s another directory that still contains this file on the classpath.
people of boot, i need your help - when i say "killer boot demo" what comes to mind?
want to do a very demo/code heavy preso tomorrow but i'm not sure in which direction to go, or what points to emphasize