@pandeiro: it's not reading from the filesystem, it's reading from the classpath

so it gets on to the classpath because it is in a directory specified in :resource-paths, right?

yes

can i make the fileset take precedence over that?

things that are in the fileset as resource files will be on the classpath

i mean you need to call commit! on the fileset to flush it to disk of course

yeah it's getting flushed to disk...

but the serve task (which is delegating to ring.util.response/resource-response) is seeing the version on disk instead of the updated fileset one

there can only be one version though

if you've called commit on the fileset they must be the same

the new one should overwrite the original, right?

that's what i expected to happen

the fileset commit operation will overwrite the previous one, yes

and i can see that in target, it's the modified file from the fileset commit

but (ring.util.response/resource-response "index.html") in this case is serving <resource-path>/index.html, not the updated fileset one

does that :loader option have any relevance here?

no, that's to set a different classloader for it to get resources from

classloaders are the things that the classpath resources live in

when you do io/resource you're asking a classloader to resolve the path and return a handle to a thing on its classpath

but it's a tree of them, so it might delegate to a higher level classloader

like DNS kind of

the classpath is the set of all paths that can be resolved by the default classloader

different pods have different default classloaders, so they can have different classpaths, too

"default classloader" isn't a technical term, it's just descriptive

so the stuff that happens to the fileset happens in the "default classloader" right?

or maybe, maybe not?

yeah basically

the one for the core pod

which is where your build.boot runs

other pods aren't affected

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?

yes

definitely

ok, huh. back to the drawing board. thanks

is that not the case?

testing now

if the file were updated, would it have two different URLs before/after the update?

(URLs b/c resources return java.net.URL)

yeah i think that's possible

the actual location on disk will change

yeah, two different boot tmp directories

potentially

right

lol man

so many thing

s

indeed: works as you prescribed

something weird must be happening there in boot-http land... i don't get it at all

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?

except one will be a java.net.URL, the other a java.io.File ?

yeah pretty much

they're both coming from the file really

via different interfaces

the classpath is the best way to get the thing because it abstracts away the mechanics of the actual resource sotrage

*storage

so "foo" might be coming from a jar file, from the internet, from a local directory, you don't need to know or care

this is really the idea behind the classpath

so you can have this environment where all the resources are accessible via the same uniform interface

the io/resource interface

no matter how they got there or where they came from

and the classloader concept supports that

it's like scoping for resources

which is really powerful

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 with-pre-wrap

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

is it running in a pod?

yeah

ah, that would explain it maybe

how is the pod created?

https://github.com/pandeiro/boot-http/blob/master/src/pandeiro/boot_http.clj#L50-L67

hm

the worker pod is an implementation detail btw

it's not really meant to be exposed for modification

dependencies in there will change etc

oh nm

i was confused

wasn't following

lol

tried moving the pod instantiation to inside with-pre-wrap but problem persists

https://github.com/pandeiro/boot-http/blob/master/src/pandeiro/boot_http.clj#L59

that's where it's setting the directories, is it correct?

i don't think that :env-dirs bit is in play here

: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

that's where the server function and the resource handler get defined

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?

or some files change and others don't?

not sure

not sure i have any other examples of a file that exists in resource-path but gets updated in pipeline and served

so (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

https://github.com/pandeiro/boot-http/issues/29 - @pandeiro is “some operation” referring to user action on the source files?

Refers to a task modifying said resource and committing it to the fileset

@pandeiro: isn’t that the same issue as https://github.com/boot-clj/boot/pull/338?

There's no watch involved here though...

ah. you mean like boot build serve or so?

Yep

sorry then. Somehow assumed watch would be used.

I tracked the resource and serve is seeing a previous version

It resolved to a boot tmp dir

But a previous one

did you put a task between build and serve that checks if the changed file is in the fileset etc?

Yep

It's there

It's updated

The tmp dir of the URL is different once the file is modified

Serve resource handler is getting the old one for some reason

@pandeiro: have you tried making a task that just tries looking it up with io/resource instead of through fileset?

if this works we could exclude any classloader related reasons I guess

Yep

That's what I was trying to describe above

Like an inspect-resource task

ah ok. I thought you looked at the file through the fileset instead of looking it up with io/resource

It seems like maybe the resources handler in serve is 'binding' to an earlier fileset 'context', eg when the NS is required

I did both

@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.

Cheers @martinklepsch I'm afk but I will try that later.

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

the audience is mostly not familiar with clj or cljs

anyway thanks in advance for any ideas you might have i'll be up for awhile yet prepping