Fork me on GitHub
#boot
<
2015-11-05
>
micha00:11:34

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

pandeiro00:11:19

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

pandeiro00:11:36

can i make the fileset take precedence over that?

micha00:11:03

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

micha00:11:17

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

pandeiro00:11:28

yeah it's getting flushed to disk...

pandeiro00:11:05

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

micha00:11:52

there can only be one version though

micha00:11:06

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

pandeiro00:11:35

the new one should overwrite the original, right?

pandeiro00:11:40

that's what i expected to happen

micha00:11:44

the fileset commit operation will overwrite the previous one, yes

pandeiro00:11:55

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

pandeiro00:11:42

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

pandeiro00:11:59

does that :loader option have any relevance here?

micha00:11:48

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

micha00:11:06

classloaders are the things that the classpath resources live in

micha00:11:30

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

micha00:11:48

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

micha00:11:52

like DNS kind of

micha00:11:45

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

micha00:11:14

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

micha00:11:37

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

pandeiro00:11:06

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

pandeiro00:11:16

or maybe, maybe not?

micha00:11:31

yeah basically

micha00:11:38

the one for the core pod

micha00:11:46

which is where your build.boot runs

micha00:11:52

other pods aren't affected

pandeiro00:11:38

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?

micha00:11:53

definitely

pandeiro00:11:38

ok, huh. back to the drawing board. thanks

micha00:11:58

is that not the case?

pandeiro00:11:12

testing now

pandeiro00:11:54

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

pandeiro00:11:38

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

micha00:11:05

yeah i think that's possible

micha00:11:29

the actual location on disk will change

pandeiro00:11:33

yeah, two different boot tmp directories

micha00:11:33

potentially

micha00:11:38

so many thing

pandeiro00:11:43

indeed: works as you prescribed

pandeiro00:11:29

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

pandeiro00:11:57

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?

pandeiro00:11:21

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

micha00:11:01

yeah pretty much

micha00:11:12

they're both coming from the file really

micha00:11:17

via different interfaces

micha00:11:53

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

micha00:11:26

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

micha00:11:39

this is really the idea behind the classpath

micha00:11:58

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

micha00:11:02

the io/resource interface

micha00:11:14

no matter how they got there or where they came from

micha00:11:25

and the classloader concept supports that

micha00:11:31

it's like scoping for resources

micha00:11:37

which is really powerful

pandeiro01:11:33

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

pandeiro01:11:34

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

micha01:11:17

is it running in a pod?

micha01:11:31

ah, that would explain it maybe

micha01:11:42

how is the pod created?

micha01:11:07

the worker pod is an implementation detail btw

micha01:11:22

it's not really meant to be exposed for modification

micha01:11:34

dependencies in there will change etc

micha01:11:02

i was confused

pandeiro01:11:05

wasn't following

pandeiro01:11:42

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

micha01:11:16

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

pandeiro02:11:14

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

pandeiro02:11:54

:resource-root below it sets an optional prefix to the path that resources try to resolve

pandeiro02:11:03

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

micha02:11:15

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?

micha02:11:27

or some files change and others don't?

pandeiro02:11:45

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

pandeiro03:11:32

so (io/resource "index.html") inside task pipeline and inside the serve handler return different URL paths

pandeiro03:11:56

the latter is identical to the path that's returned on the resource before it's modified in the pipeline

martinklepsch13:11:42

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

pandeiro13:11:52

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

martinklepsch13:11:11

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

pandeiro13:11:58

There's no watch involved here though...

martinklepsch13:11:27

ah. you mean like boot build serve or so?

martinklepsch13:11:40

sorry then. Somehow assumed watch would be used.

pandeiro13:11:00

I tracked the resource and serve is seeing a previous version

pandeiro13:11:31

It resolved to a boot tmp dir

pandeiro13:11:40

But a previous one

martinklepsch13:11:25

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

pandeiro13:11:39

It's updated

pandeiro13:11:35

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

pandeiro13:11:49

Serve resource handler is getting the old one for some reason

martinklepsch13:11:05

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

martinklepsch13:11:32

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

pandeiro13:11:22

That's what I was trying to describe above

pandeiro13:11:34

Like an inspect-resource task

martinklepsch14:11:14

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

pandeiro14:11:47

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

pandeiro14:11:11

I did both

martinklepsch14:11:09

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

pandeiro15:11:12

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

alandipert23:11:20

people of boot, i need your help - when i say "killer boot demo" what comes to mind?

alandipert23:11:38

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

alandipert23:11:44

the audience is mostly not familiar with clj or cljs

alandipert23:11:34

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